shorewall-docs-xml-4.5.21/0000755000175000017500000000000012223303501015212 5ustar teastepteastepshorewall-docs-xml-4.5.21/blacklisting_support.xml0000644000175000017500000003333112222401136022203 0ustar teastepteastep
Shorewall Blacklisting/Whitelisting Support Tom Eastep 2002-2006 2010 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.4 and later. If you are running a version of Shorewall earlier than Shorewall 4.3.5 then please see the documentation for that release.
Introduction Shorewall supports two different types of blackliisting; rule-based, static and dynamic. The BLACKLISTNEWONLY option in /etc/shorewall/shorewall.conf controls the degree of blacklist filtering: BLACKLISTNEWONLY=No -- All incoming packets are checked against the blacklist. New blacklist entries can be used to terminate existing connections. BLACKLISTNEWONLY=Yes -- The blacklists are only consulted for new connection requests. Blacklists may not be used to terminate existing connections. For automatic blacklisting based on exceeding defined threshholds, see Events.
Rule-based Blacklisting Beginning with Shorewall 4.4.25, the preferred method of blacklisting and whitelisting is to use the blrules file (shorewall-blrules (5)). There you have access to the DROP, ACCEPT, REJECT and WHITELIST actions, standard and custom macros as well as standard and custom actions. See shorewall-rules (5) for details. Example: #ACTION SOURCE DEST PROTO DEST # PORTS(S) SECTION BLACKLIST WHITELIST net:70.90.191.126 all DROP net all udp 1023:1033,1434,5948,23773 DROP all net udp 1023:1033 DROP net all tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,5948,6101,8081,9898,23773 DROP net:221.192.199.48 all DROP net:61.158.162.9 all DROP net:81.21.54.100 all tcp 25 DROP net:84.108.168.139 all DROP net:200.55.14.18 all Beginning with Shorewall 4.4.26, the update command supports a option that causes your legacy blacklisting configuration to use the blrules file. If you prefer to keep your blacklisting rules in your rules file (shorewall-rules (5)), you can place them in the BLACKLIST section of that file rather than in blrules.
Legacy Blacklisting Prior to 4.4.25, two forms of blacklisting were supported; static and dynamic. The dynamic variety is still appropriate for on-the-fly blacklisting; the static form is deprecated. By default, only the source address is checked against the blacklists. Blacklists only stop blacklisted hosts from connecting to you — they do not stop you or your users from connecting to blacklisted hosts . UPDATE Beginning with Shorewall 4.4.12, you can also blacklist by destination address. See shorewall-blacklist (5) and shorewall (8) for details. Dynamic Shorewall blacklisting is not appropriate for blacklisting 1,000s of different addresses. Static Blacklisting can handle large blacklists but only if you use ipsets. Without ipsets, the blacklists will take forever to load, and will have a very negative effect on firewall performance.
Static Blacklisting Shorewall static blacklisting support has the following configuration parameters: You specify whether you want packets from blacklisted hosts dropped or rejected using the BLACKLIST_DISPOSITION setting in shorewall.conf(5). You specify whether you want packets from blacklisted hosts logged and at what syslog level using the BLACKLIST_LOGLEVEL setting in shorewall.conf(5). You list the IP addresses/subnets that you wish to blacklist in shorewall-blacklist (5). You may also specify PROTOCOL and Port numbers/Service names in the blacklist file. You specify the interfaces whose incoming packets you want checked against the blacklist using the blacklist option in shorewall-interfaces(5) (shorewall-zones(5) in Shorewall 4.4.12 and later). Prior to Shorewall 4.4.20, only source-address static blacklisting was supported. Users with a large static black list may want to set the DELAYBLACKLISTLOAD option in shorewall.conf (added in Shorewall version 2.2.0). When DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before loading the blacklist rules. While this may allow connections from blacklisted hosts to slip by during construction of the blacklist, it can substantially reduce the time that all new connections are disabled during "shorewall [re]start". Beginning with Shorewall 2.4.0, you can use ipsets to define your static blacklist. Here's an example: #ADDRESS/SUBNET PROTOCOL PORT +Blacklistports[dst] +Blacklistnets[src,dst] +Blacklist[src,dst] #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE In this example, there is a portmap ipset Blacklistports that blacklists all traffic with destination ports included in the ipset. There are also Blacklistnets (type nethash) and Blacklist (type iphash) ipsets that allow blacklisting networks and individual IP addresses. Note that [src,dst] is specified so that individual entries in the sets can be bound to other portmap ipsets to allow blacklisting (source address, destination port) combinations. For example: 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 This will blacklist SMTP traffic from host 206.124.146.177.
Static Whitelisting Beginning with Shorewall 4.4.20, you can create whitelist entries in the blacklist file. Connections/packets matching a whitelist entry are not matched against the entries in the blacklist file that follow. Whitelist entries are created using the whitelist option (OPTIONS column). See shorewall-blacklist (5).
Dynamic Blacklisting Beginning with Shorewall 4.4.7, dynamic blacklisting is enabled by setting DYNAMIC_BLACKLIST=Yes in shorewall.conf. Prior to that release, the feature is always enabled. Once enabled, dynamic blacklisting doesn't use any configuration parameters but is rather controlled using /sbin/shorewall[-lite] commands. Note that to and from may only be specified when running Shorewall 4.4.12 or later. drop [to|from] <ip address list> - causes packets from the listed IP addresses to be silently dropped by the firewall. reject [to|from]<ip address list> - causes packets from the listed IP addresses to be rejected by the firewall. allow [to|from] <ip address list> - re-enables receipt of packets from hosts previously blacklisted by a drop or reject command. save - save the dynamic blacklisting configuration so that it will be automatically restored the next time that the firewall is restarted. Update: Beginning with Shorewall 4.4.10, the dynamic blacklist is automatically retained over stop/start sequences and over restart. show dynamic - displays the dynamic blacklisting configuration. logdrop [to|from] <ip address list> - causes packets from the listed IP addresses to be dropped and logged by the firewall. Logging will occur at the level specified by the BLACKLIST_LOGLEVEL setting at the last [re]start (logging will be at the 'info' level if no BLACKLIST_LOGLEVEL was given). logreject [to|from}<ip address list> - causes packets from the listed IP addresses to be rejected and logged by the firewall. Logging will occur at the level specified by the BLACKLIST_LOGLEVEL setting at the last [re]start (logging will be at the 'info' level if no BLACKLIST_LOGLEVEL was given). Dynamic blacklisting is not dependent on the blacklist option in /etc/shorewall/interfaces. Ignore packets from a pair of systems shorewall[-lite] drop 192.0.2.124 192.0.2.125 Drops packets from hosts 192.0.2.124 and 192.0.2.125 Re-enable packets from a system shorewall[-lite] allow 192.0.2.125 Re-enables traffic from 192.0.2.125. Displaying the Dynamic Blacklist shorewall show dynamic Displays the 'dynamic' chain which contains rules for the dynamic blacklist. The source column contains the set of blacklisted addresses.
shorewall-docs-xml-4.5.21/XenMyWay-Routed.xml0000644000175000017500000013432212222401136020724 0ustar teastepteastep
Strong Firewall in a Routed Xen Dom0 Tom Eastep 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. 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 Xen Prior to adopting Xen, I had a home office crowded with 5 systems, three monitors a scanner and a printer. The systems were: Firewall Public Server in a DMZ (mail) Private Server (wookie) My personal Linux Desktop (ursa) My work system (docked laptop running Windows XP). The result was a very crowded and noisy room.
After Xen Xen has allowed me to reduce the noise and clutter considerably. I now have three systems with two monitors. I've also replaced the individual printer and scanner with a Multifunction FAX/Scanner/Printer. The systems now include: Combination Firewall/Public Server/Private Server/Wireless Gateway using Xen (created by building out my Linux desktop system -- Now replaced by a Hewlett-Packard Pavilion a1510y). My work system. My Linux desktop (wookie, which is actually the old public server box) The Linux systems run either OpenSuSE 10.3 or Ubuntu "Gutsy Gibbon". Here is a high-level diagram of our network. As shown in this diagram, the Xen system has three physical network interfaces. These are: eth0 -- connected to our DSL "Modem". eth1 -- connected to the switch in my office. eth2 -- connected to a Wireless Access Point (WAP) that interfaces to our wireless network. There are three Xen domains. Dom0 (DNS name gateway.shorewall.net) is used as our main firewall and wireless gateway as well as a local file server. It hosts Squid running as a transparent HTTP proxy and a DHCP server that manages IP address assignment for both the LAN and the Wireless network. A DomU (Domain name lists, DNS name lists.shorewall.net) that is used as a public Web/FTP/Mail/DNS server. A DomU (Domain name test, DNS name test.shorewall.net) that I use for Shorewall testing. Shorewall runs in Dom0. As the developer of Shorewall, I have enough experience to be very comfortable with Linux networking and Shorewall/iptables. I arrived at this configuration after a fair amount of trial and error experimentation (see Xen and the art of Consolidation). If you are a Linux networking novice, I recommend that you do not attempt a configuration like this one for your first Shorewall installation. You are very likely to frustrate both yourself and the Shorewall support team. Rather I suggest that you start with something simple like a standalone installation in a DomU; once you are comfortable with that then you will be ready to try something more substantial. As Paul Gear says: Shorewall might make iptables easy, but it doesn't make understanding fundamental networking principles, traffic shaping, or multi-ISP routing any easier. The same goes for Xen networking.
Domain Configuration Below are the relevant configuration files for the two domains. I use a partition on my hard drives for the DomU storage device. There is not much documentation about how to configure Xen for routed operation. I've tried to mark the relevant parts with bold font. The files from /etc/xen/auto shown below correspond to my configuration under Xen 3.0. I'm now running Xen 3.1 which does not use configuration files for the domains but rather keeps the configuration in a database managed by xend. See below.
/boot/grub/menu.lst — here is the entry that boots Xen in Dom0.
title Kernel-2.6.18.8-0.1-xen root (hd0,5) kernel /boot/xen.gz module /boot/vmlinuz-2.6.18.8-0.1-xen root=/dev/sda6 vga=0x31a resume=/dev/sda5 splash=silent showopts module /boot/initrd-2.6.18.8-0.1-xen
/etc/modprobe.conf.local (This may need to go in /etc/modprobe.conf or /etc/modprobe.d/options on your system)
options netloop nloopbacks=0 #Stop netloop from creating 8 useless vifs
/etc/xen/auto/01-lists — configuration file for the lists domain. Placed in /etc/xen/auto/ so it is started automatically by Xen's xendomains service.
disk = [ 'phy:/dev/sda9,hda,w', 'phy:/dev/hda,hdb,r' ] memory = 512 vcpus = 1 builder = 'linux' name = 'server' vif = [ 'mac=00:16:3e:b1:d7:90, ip=206.124.146.177, vifname=eth3' ] localtime = 0 on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' extra = ' TERM=xterm' bootloader = '/usr/lib/xen/boot/domUloader.py' bootentry = 'hda2:/boot/vmlinuz-xen,/boot/initrd-xen' Note that the vifname is set to 'eth3' for the virtual interface to this DomU. This will cause the Dom0 interface to the server to have a fixed name (eth3) which makes it a lot easier to deal with in Shorewall and elsewhere. Specifying an IP address (ip=206.124.146.177) causes the vif-route script to create a host route to that IP address on eth3.
gateway:~ # ip route ls dev eth3 206.124.146.177 scope link src 206.124.146.176 gateway:~ #
Note that the source for the route is 206.124.146.176. That is the primary IP address of Dom0's eth0. Xen configures eth3 to have that same IP address.
/etc/xen/auto/02-test — configuration file for the test domain.
disk = [ 'phy:/dev/hdb4,hda,w', 'phy:/dev/hda,hdb,r' ] memory = 512 vcpus = 1 builder = 'linux' name = 'test' vif = [ 'mac=00:16:3e:83:ad:28, ip=192.168.1.7, vifname=eth4' ] localtime = 0 on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' extra = ' TERM=xterm' bootloader = '/usr/lib/xen/boot/domUloader.py' bootentry = 'hda2:/boot/vmlinuz-xen,/boot/initrd-xen'
Excerpt from /etc/xen/xend-config.sxp:
… # It is possible to use the network-bridge script in more complicated # scenarios, such as having two outgoing interfaces, with two bridges, and # two fake interfaces per guest domain. To do things like this, write # yourself a wrapper script, and call network-bridge from it, as appropriate. # #(network-script network-bridge) … # If you are using only one bridge, the vif-bridge script will discover that, # so there is no need to specify it explicitly. # #(vif-script vif-bridge) ## Use the following if network traffic is routed, as an alternative to the # settings for bridged networking given above. (network-script network-route) (vif-script vif-route) As of this writing, the vif-route script does not set up Proxy ARP correctly. So the domU can communicate with the dom0 but not with hosts beyond the dom0. If you configure Shorewall as described below, Shorewall will correct the Proxy ARP configuration so that it will work.
Instructions for editing entries in the Xen 3.1 xend database may be found at http://www.novell.com/documentation/vmserver/config_options/index.html?page=/documentation/vmserver/config_options/data/b8uh3zr.html, The following are excerpts from the XML representations of the two user domains (produced by "xm list -l …"). lists domain:
… (features ) (on_xend_start start) (on_xend_stop shutdown) (start_time 1194710550.49) … (console_mfn 397179) (device (vif (mac 00:16:3e:b1:d7:90) (script vif-route) (ip 206.124.146.177) (vifname eth3) (type netfront) (devid 0) (uuid 55676385-7b69-09fd-4027-751b692ead75) ) ) (device (vbd …
test domain:
… (console_mfn 418003) (device (vif (uuid 64a1dd48-fa8b-7561-e90b-cd589cbeb7fa) (script vif-route) (ip 192.168.1.7) (mac 00:16:3e:83:ad:28) (vifname eth4) (devid 0) (type netfront) (backend 0) ) ) (device (vbd …
With the three Xen domains up and running, the system looks as shown in the following diagram. The zones correspond to the Shorewall zones in the Dom0 configuration. Readers who are paying attention will notice that eth4 has the same public IP address (206.124.146.176) as eth0 (and eth3), yet the test system connected to that interface has an RFC 1918 address (192.168.1.7). That configuration is established by Xen which clones the primary IP address of eth0 on all of the routed virtual interfaces that it creates. test is configured with it's default route via 192.168.1.254 which is the IP address of the firewall's br0. That works because of the way that the Linux network stack treats local IPv4 addresses; by default, it will respond to ARP "who-has" broadcasts for any local address and not just for the addresses on the interface that received the broadcast (but of course the MAC address returned in the "here-is" response is that of the interface that received the broadcast). So when test broadcasts "who-has 192.168.1.254", the firewall responds with "here-is 192.168.1.254 00:16:3e:83:ad:28" (00:16:3e:83:ad:28 is the MAC of virtual interface eth4). Under some circumstances, UDP and/or TCP communication from a DomU won't work for no obvious reason. That happened with the lists domain in my setup. Looking at the IP traffic with tcpdump -nvvi eth1 in Dom0 showed that UDP packets from the lists DomU had incorrect checksums. That problem was corrected by arranging for the following command to be executed in the lists and test domains when the eth0 device was brought up: ethtool -K eth0 tx off Under OpenSuSE 10.2, I placed the following in /etc/sysconfig/network/ifcfg-eth-id-00:16:3e:b1:d7:90 (the config file for eth0): ETHTOOL_OPTIONS='-K iface tx off' Under other distributions, the technique will vary. For example, under Debian or Ubuntu, you can just add a 'post-up' entry to /etc/network/interfaces as shown here: iface eth0 inet static address 206.124.146.177 netmask 255.255.255.0 post-up ethtool -K eth0 tx off Update. Under OpenSuSE 10.2, communication from a domU works okay without running ethtool but traffic shaping in dom0 doesn't work! So it's a good idea to run it just to be safe.
Dom0 Shorewall Configuration In Dom0, I run a conventional three-interface firewall with Proxy ARP DMZ -- it is very similar to the firewall described in the Shorewall Setup Guide with the exception that I've added a fourth interface for our wireless network. The firewall runs a routed OpenVPN server to provide road warrior access for our three laptops and a bridged OpenVPN server for the wireless network in our home. Here is the firewall's view of the network: The three laptops can be directly attached to the LAN as shown above or they can be attached wirelessly -- their IP addresses are the same in either case; when they are directly attached, the IP address is assigned by the DHCP server running in Dom0 and when they are attached wirelessly, the IP address is assigned by OpenVPN. The Shorewall configuration files are shown below. All routing and secondary IP addresses are handled in the OpenSuSE network configuration.
/etc/shorewall/shorewall.conf STARTUP_ENABLED=Yes VERBOSITY=0 SHOREWALL_COMPILER=perl LOGFILE=/var/log/firewall LOGFORMAT="Shorewall:%s:%s:" LOGTAGONLY=No LOGRATE= LOGBURST= LOGALLNEW= BLACKLIST_LOGLEVEL= MACLIST_LOG_LEVEL=$LOG TCP_FLAGS_LOG_LEVEL=$LOG SMURF_LOG_LEVEL=$LOG LOG_MARTIANS=No IPTABLES= SHOREWALL_SHELL=/bin/ash SUBSYSLOCK=/var/lock/subsys/shorewall MODULESDIR= CONFIG_PATH=/etc/shorewall:/usr/share/shorewall RESTOREFILE= IPSECFILE=zones LOCKFILE= DROP_DEFAULT="Drop" REJECT_DEFAULT="Reject" ACCEPT_DEFAULT="none" QUEUE_DEFAULT="none" IP_FORWARDING=Yes ADD_IP_ALIASES=No ADD_SNAT_ALIASES=No RETAIN_ALIASES=No TC_ENABLED=internal TC_EXPERT=No CLEAR_TC=Yes MARK_IN_FORWARD_CHAIN=Yes CLAMPMSS=Yes ROUTE_FILTER=No DETECT_DNAT_IPADDRS=Yes MUTEX_TIMEOUT=60 ADMINISABSENTMINDED=Yes BLACKLISTNEWONLY=Yes DELAYBLACKLISTLOAD=No MODULE_SUFFIX= DISABLE_IPV6=Yes BRIDGING=No DYNAMIC_ZONES=No PKTTYPE=No MACLIST_TABLE=mangle MACLIST_TTL=60 SAVE_IPSETS=No MAPOLDACTIONS=No FASTACCEPT=Yes IMPLICIT_CONTINUE=Yes HIGH_ROUTE_MARKS=Yes USE_ACTIONS=Yes OPTIMIZE=1 EXPORTPARAMS=No EXPAND_POLICIES=Yes KEEP_RT_TABLES=No DELETE_THEN_ADD=No BLACKLIST_DISPOSITION=DROP MACLIST_DISPOSITION=DROP TCP_FLAGS_DISPOSITION=DROP /etc/shorewall/zones: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall #The firewall itself. net ipv4 #Internet loc ipv4 #Local wired Zone dmz ipv4 #DMZ vpn ipv4 #Open VPN clients wifi ipv4 #Local Wireless Zone #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE /etc/shorewall/policy: #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL $FW $FW ACCEPT $FW net ACCEPT loc net ACCEPT $FW vpn ACCEPT vpn net ACCEPT vpn loc ACCEPT loc vpn ACCEPT $FW loc ACCEPT loc $FW ACCEPT wifi all REJECT $LOG net $FW DROP $LOG 1/sec:2 net loc DROP $LOG 2/sec:4 net dmz DROP $LOG 8/sec:30 net vpn DROP $LOG all all REJECT $LOG #LAST LINE -- DO NOT REMOVE Note that the firewall<->local network interface is wide open so from a security point of view, the firewall system is part of the local zone. /etc/shorewall/params (edited): MIRRORS=<comma-separated list of Shorewall mirrors> NTPSERVERS=<comma-separated list of NTP servers I sync with> POPSERVERS=<comma-separated list of server IP addresses> LOG=info INT_IF=br0 DMZ_IF=eth3 EXT_IF=eth0 WIFI_IF=eth2 TEST_IF=eth4 OMAK=<IP address at our second home> #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE /etc/shorewall/init: echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal /etc/shorewall/interfaces (don't specify the BROADCAST addresses if you are using Shorewall-perl): #ZONE INTERFACE BROADCAST OPTIONS net ${EXT_IF} detect dhcp,logmartians=1,blacklist dmz $DMZ_IF detect logmartians=1 loc $INT_IF detect dhcp,logmartians=1,routeback,bridge loc $TEST_IF detect optional loc $TEST1_IF detect optional wifi $WIFI_IF detect dhcp,maclist,mss=1400 vpn tun+ - #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/nat: #EXTERNAL INTERFACE INTERNAL ALL LOCAL # INTERFACES COMMENT One-to-one NAT 206.124.146.178 $EXT_IF:0 192.168.1.3 No No 206.124.146.180 $EXT_IF:2 192.168.1.6 No No #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE /etc/shorewall/masq (Note the cute trick here and in the following proxyarp file that allows me to access the DSL "Modem" using its default IP address (192.168.1.1)). The leading "+" is required to place the rule before the SNAT rules generated by entries in /etc/shorewall/nat above. #INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC COMMENT Handle DSL 'Modem' +$EXT_IF:192.168.1.1 0.0.0.0/0 192.168.1.254 COMMENT Masquerade VPN clients and Wifi $EXT_IF 192.168.2.0/24 $EXT_IF 192.168.3.0/24 $EXT_IF:192.168.98.1 192.168.99.1 192.168.1.99 $EXT_IF:192.168.99.1 192.168.98.1 192.168.1.98 COMMENT Masquerade Local Network $EXT_IF $INT_IF 206.124.146.179 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE /etc/shorewall/proxyarp: #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 192.168.1.1 $EXT_IF $INT_IF yes 206.124.146.177 $DMZ_IF $EXT_IF yes 192.168.1.7 $TEST_IF $INT_IF yes #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/tunnels: #TYPE ZONE GATEWAY GATEWAY # ZONE openvpnserver:udp net 0.0.0.0/0 #Routed server for RoadWarrior access openvpnserver:udp wifi 192.168.3.0/24 #Home wireless network server #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/blacklist: #ADDRESS/SUBNET PROTOCOL PORT - udp 1024:1033,1434 - tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898 #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE /etc/shorewall/actions: #ACTION Mirrors # Accept traffic from Shorewall Mirrors #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE /etc/shorewall/action.Mirrors: #TARGET SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE # PORT PORT(S) DEST LIMIT ACCEPT $MIRRORS #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/rules: SECTION NEW ############################################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT PORT(S) DEST LIMIT GROUP ############################################################################################################################################################################### REJECT:$LOG loc net tcp 25 REJECT:$LOG loc net udp 1025:1031 # # Stop NETBIOS crap # REJECT loc net tcp 137,445 REJECT loc net udp 137:139 # # 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 ############################################################################################################################################################################### # Local Network to Firewall # REDIRECT- loc 3128 tcp 80 - !192.168.1.1,192.168.0.7,206.124.146.177,155.98.64.80 ############################################################################################################################################################################### # Road Warriors to Firewall # ACCEPT vpn fw tcp ssh,time,631,8080 ACCEPT vpn fw udp 161,ntp,631 Ping(ACCEPT) vpn fw ############################################################################################################################################################################### # Road Warriors to DMZ # ACCEPT vpn dmz udp domain ACCEPT vpn dmz tcp www,smtp,smtps,domain,ssh,imap,https,imaps,ftp,10023,pop3 - Ping(ACCEPT) vpn dmz ############################################################################################################################################################################### # Local network to DMZ # ACCEPT loc dmz udp domain ACCEPT loc dmz tcp ssh,smtps,www,ftp,imaps,domain,https - ACCEPT loc dmz tcp smtp Trcrt(ACCEPT) loc dmz ############################################################################################################################################################################### # Internet to ALL -- drop NewNotSyn packets # dropNotSyn net fw tcp #dropNotSyn net loc tcp dropNotSyn net dmz tcp ############################################################################################################################################################################### # Internet to DMZ # ACCEPT net dmz udp domain LOG:$LOG net:64.126.128.0/18 dmz tcp smtp ACCEPT net dmz tcp smtps,www,ftp,imaps,domain,https - ACCEPT net dmz tcp smtp - 206.124.146.177,206.124.146.178 ACCEPT net dmz udp 33434:33454 Mirrors net dmz tcp rsync Limit:$LOG:SSHA,3,60\ net dmz tcp 22 Trcrt(ACCEPT) net dmz ############################################################################################################################################################################## # # Net to Local # # When I'm "on the road", the following two rules allow me VPN access back home using PPTP. # DNAT net loc:192.168.1.4 tcp 1729 DNAT net loc:192.168.1.4 gre # # Roadwarrior access to Ursa # ACCEPT net:$OMAK loc tcp 22 Limit:$LOG:SSHA,3,60\ net loc tcp 22 # # ICQ # ACCEPT net loc:192.168.1.3 tcp 113,4000:4100 # # Bittorrent # ACCEPT net loc:192.168.1.3 tcp 6881:6889,6969 ACCEPT net loc:192.168.1.3 udp 6881:6889,6969 # # Real Audio # ACCEPT net loc:192.168.1.3 udp 6970:7170 # # Overnet # #ACCEPT net loc:192.168.1.3 tcp 4662 #ACCEPT net loc:192.168.1.3 udp 12112 # # OpenVPN # ACCEPT net loc:192.168.1.3 udp 1194 ACCEPT net loc:192.168.1.6 udp 1194 # Skype # ACCEPT net loc:192.168.1.6 tcp 1194 # # Traceroute # Trcrt(ACCEPT) net loc:192.168.1.3 # # Silently Handle common probes # REJECT net loc tcp www,ftp,https DROP net loc icmp 8 ############################################################################################################################################################################### # DMZ to Internet # ACCEPT dmz net udp domain,ntp ACCEPT dmz net tcp echo,ftp,ssh,smtp,whois,domain,www,81,https,cvspserver,2702,2703,8080 ACCEPT dmz net:$POPSERVERS tcp pop3 Ping(ACCEPT) dmz net # # Some FTP clients seem prone to sending the PORT command split over two packets. This prevents the FTP connection tracking # code from processing the command and setting up the proper expectation. The following rule allows active FTP to work in these cases # but logs the connection so I can keep an eye on this potential security hole. # ACCEPT:$LOG dmz net tcp 1024: 20 ############################################################################################################################################################################### # Local to DMZ # ACCEPT loc dmz udp domain,xdmcp ACCEPT loc dmz tcp www,smtp,smtps,domain,ssh,imap,rsync,https,imaps,ftp,10023,pop3,3128 Trcrt(ACCEPT) loc dmz ############################################################################################################################################################################### # DMZ to Local # ACCEPT dmz loc:192.168.1.5 udp 123 ACCEPT dmz loc:192.168.1.5 tcp 21 Ping(ACCEPT) dmz loc ############################################################################################################################################################################### # DMZ to Firewall -- ntp & snmp, Silently reject Auth # #ACCEPT net loc:192.168.1.3 udp 12112 # # OpenVPN # ACCEPT net loc:192.168.1.3 udp 1194 ACCEPT net loc:192.168.1.6 udp 1194 # Skype # ACCEPT net loc:192.168.1.6 tcp 1194 # # Traceroute # Trcrt(ACCEPT) net loc:192.168.1.3 # # Silently Handle common probes # REJECT net loc tcp www,ftp,https DROP net loc icmp 8 ############################################################################################################################################################################### # DMZ to Internet # ACCEPT dmz net udp domain,ntp ACCEPT dmz net tcp echo,ftp,ssh,smtp,whois,domain,www,81,https,cvspserver,2702,2703,8080 ACCEPT dmz net:$POPSERVERS tcp pop3 Ping(ACCEPT) dmz net # # Some FTP clients seem prone to sending the PORT command split over two packets. This prevents the FTP connection tracking # code from processing the command and setting up the proper expectation. The following rule allows active FTP to work in these cases # but logs the connection so I can keep an eye on this potential security hole. # ACCEPT:$LOG dmz net tcp 1024: 20 ############################################################################################################################################################################### # Local to DMZ # ACCEPT loc dmz udp domain,xdmcp ACCEPT loc dmz tcp www,smtp,smtps,domain,ssh,imap,rsync,https,imaps,ftp,10023,pop3,3128 Trcrt(ACCEPT) loc dmz ############################################################################################################################################################################### # DMZ to Local # ACCEPT dmz loc:192.168.1.5 udp 123 ACCEPT dmz loc:192.168.1.5 tcp 21 Ping(ACCEPT) dmz loc ############################################################################################################################################################################### # DMZ to Firewall -- ntp & snmp, Silently reject Auth # ACCEPT loc dmz udp domain,xdmcp ACCEPT loc dmz tcp www,smtp,smtps,domain,ssh,imap,rsync,https,imaps,ftp,10023,pop3,3128 Trcrt(ACCEPT) loc dmz ############################################################################################################################################################################### # DMZ to Local # ACCEPT dmz loc:192.168.1.5 udp 123 ACCEPT dmz loc:192.168.1.5 tcp 21 Ping(ACCEPT) dmz loc ############################################################################################################################################################################### # DMZ to Firewall -- ntp & snmp, Silently reject Auth # ACCEPT dmz fw tcp 161,ssh ACCEPT dmz fw udp 161,ntp REJECT dmz fw tcp auth Ping(ACCEPT) dmz fw ############################################################################################################################################################################### # Internet to Firewall # REJECT net fw tcp www,ftp,https DROP net fw icmp 8 ACCEPT net fw udp 33434:33454 ACCEPT net:$OMAK fw udp ntp ACCEPT net fw tcp auth ACCEPT net:$OMAK fw tcp 22 Limit:$LOG:SSHA,3,60\ net fw tcp 22 Trcrt(ACCEPT) net fw # # Bittorrent # ACCEPT net fw tcp 6881:6889,6969 ACCEPT net fw udp 6881:6889,6969 ############################################################################################################################################################################### # Firewall to DMZ # ACCEPT fw dmz tcp domain,www,ftp,ssh,smtp,https,993,465 ACCEPT fw dmz udp domain REJECT fw dmz udp 137:139 Ping(ACCEPT) fw dmz ############################################################################################################################################################################## # Avoid logging Freenode.net probes # DROP net:82.96.96.3 all #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/tcdevices #INTERFACE IN-BANDWITH OUT-BANDWIDTH $EXT_IF 1300kbit 384kbit #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/tcclasses#INTERFACE MARK RATE CEIL PRIORITY OPTIONS $EXT_IF 10 5*full/10 full 1 tcp-ack,tos-minimize-delay $EXT_IF 20 3*full/10 9*full/10 2 default $EXT_IF 30 2*full/10 6*full/10 3 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/tcrules#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST # PORT(S) 1:110 192.168.0.0/22 $EXT_IF #Our internal nets get priority #over the server 1:130 206.124.146.177 $EXT_IF tcp - 873 #Throttle rsync traffic to the #Shorewall Mirrors. #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
The tap0 device used by the bridged OpenVPN server is created and bridged to eth1 using a SUSE-specific SysV init script:
#!/bin/sh # # The Shoreline Firewall (Shorewall) Packet Filtering Firewall - V3.0 # # This program is under GPL [http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt] # # (c) 1999,2000,2001,2002,2003,2004,2005 - Tom Eastep (teastep@shorewall.net) # # On most distributions, this file should be called /etc/init.d/shorewall. # # Complete documentation is available at http://shorewall.net # # This program is free software; you can redistribute it and/or modify # it under the terms of Version 2 of the GNU General Public License # as published by the Free Software Foundation. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. # # If an error occurs while starting or restarting the firewall, the # firewall is automatically stopped. # # Commands are: # # bridge start Starts the bridge # bridge restart Restarts the bridge # bridge reload Restarts the bridge # bridge stop Stops the bridge # bridge status Displays bridge status # # chkconfig: 2345 4 99 # description: Packet filtering firewall ### BEGIN INIT INFO # Provides: bridge # Required-Start: boot.udev # Required-Stop: # Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Description: starts and stops the bridge ### END INIT INFO ################################################################################ # Interfaces to be bridged -- may be listed by device name or by MAC # INTERFACES="eth1" # # Tap Devices # TAPS="tap0" ################################################################################ # Give Usage Information # ################################################################################ usage() { echo "Usage: $0 start|stop|reload|restart|status" exit 1 } ################################################################################# # Find the interface with the passed MAC address ################################################################################# find_interface_by_mac() { local mac mac=$1 local first local second local rest local dev /sbin/ip link ls | while read first second rest; do case $first in *:) dev=$second ;; *) if [ "$second" = $mac ]; then echo ${dev%:} return fi esac done } ################################################################################ # Convert MAC addresses to interface names ################################################################################ get_interfaces() { local interfaces interfaces= local interface for interface in $INTERFACES; do case $interface in *:*:*) interface=$(find_interface_by_mac $interface) [ -n "$interface" ] || echo "WARNING: Can't find an interface with MAC address $mac" ;; esac interfaces="$interfaces $interface" done INTERFACES="$interfaces" } ################################################################################ # Start the Bridge ################################################################################ do_start() { local interface get_interfaces for interface in $TAPS; do /usr/sbin/openvpn --mktun --dev $interface done /sbin/brctl addbr br0 for interface in $INTERFACES $TAPS; do /sbin/ip link set $interface up /sbin/brctl addif br0 $interface done } ################################################################################ # Stop the Bridge ################################################################################ do_stop() { local interface get_interfaces for interface in $INTERFACES $TAPS; do /sbin/brctl delif br0 $interface /sbin/ip link set $interface down done /sbin/ip link set br0 down /sbin/brctl delbr br0 for interface in $TAPS; do /usr/sbin/openvpn --rmtun --dev $interface done } ################################################################################ # E X E C U T I O N B E G I N S H E R E # ################################################################################ command="$1" case "$command" in start) do_start ;; stop) do_stop ;; restart|reload) do_stop do_start ;; status) /sbin/brctl show ;; *) usage ;; esac
shorewall-docs-xml-4.5.21/support.xml0000644000175000017500000004666712222401136017475 0ustar teastepteastep
Shorewall Support Guide 2001-20011 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 release is 4.5. 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 90 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 2> /tmp/trace Forward the /tmp/trace file as an attachment compressed with gzip or bzip2 (If you are running Shorewall-perl, there is no need to compress the file — it will be very short). 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/status.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-4.5.21/fallback.xml0000644000175000017500000000554612222401136017507 0ustar teastepteastep
Fallback and Uninstall 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.
Falling Back to the Previous Version of Shorewall using the Fallback Script If you install Shorewall and discover that it doesn't work for you, you can fall back to your previously installed version. To do that: cd to the distribution directory for the version of Shoreline Firewall that you want to fall back to. Type ./install.sh
Falling Back to the Previous Version of Shorewall using rpm If your previous version of Shorewall was installed using RPM, you may fall back to that version by typing rpm -Uvh --force <old rpm> at a root shell prompt (Example: rpm -Uvh --force /downloads/shorewall-3.1.1-0.noarch.rpm would fall back to the 3.1.1-0 version of Shorewall).
Uninstalling Shorewall If you no longer wish to use Shorewall, you may remove it by: cd to the distribution directory for the version of Shorewall that you have installed. type ./uninstall.sh If you installed using an rpm, at a root shell prompt type rpm -e shorewall. If you specified LIBEXEC and/or PERLLIB when you installed Shorewall, you must specify the same value to the uninstall script. e.g., LIBEXEC=libexec ./uninstall.sh.
shorewall-docs-xml-4.5.21/shorewall_logging.xml0000644000175000017500000003352012222401136021447 0ustar teastepteastep
Shorewall Logging 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.
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 ULOG target support (and most vendor-supplied kernels do), you may also specify a log level of ULOG (must be all caps). When ULOG 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 ULOG 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 ULOG - 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=ULOG 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, a successor to ULOG, is supported shorewall. Both ULOG and NFLOG may be followed by a list of up to three numbers in parentheses. The first number specifies the netlink group (1-32). If omitted (e.g., NFLOG(,0,10)) then a value of 1 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 DEST # PORT(S) ACCEPT:NFLOG(1,0,1) vpn fw tcp ssh,time,631,8080
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.
shorewall-docs-xml-4.5.21/Helpers.xml0000644000175000017500000004253412222401136017350 0ustar teastepteastep
Netfilter Helpers 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.
Helpers - Introduction There are a number of applications that create connections dynamically between a client and server. These connections use temporary TCP or UDP ports, so static configuration of firewall rules to allow those connections would require a very lax firewall configuration. To deal with these problem applications, Netfilter supports the concept of a helper. Each helper monitors traffic to/from the default primary port used by the application and opens the firewall to accept temporary connections created by the primary session. There are helpers for the following applications; default ports monitored by each helper are listed in parentheses: Amanda (UDP 10080) FTP (TCP 21) H323 (UDP 1719, TCP 1720) IRC (TCP 6667) Netbios-NS (UDP 137) PPTP (TCP 1729) SANE (TCP 6566) SIP (UDP 5060) SNMP (UDP 161) TFTP (UDP 69)
Helper Module Loading In a modular kernel, each helper is typically packaged as two kernel modules. One module handles connection tracking where NAT isn't involved and the other module handles NAT. For example, the FTP helper consists of these two modules (kernels 2.6.20 and later): nf_conntrack_ftp nf_nat_ftp Note that the naming convention is nf_conntrack_application and nf_nat_application; more about that below. The modules are not auto-loaded and must be loaded explicitly using the modprob or insmod utilities. Many of the modules allow parameters to be specified when the module is loaded. Among the common parameters is the ports parameter that lists one or more ports that the module is to monitor. This allows running the application on a non-standard port.
Iptables and Helpers Iptables supports two ways of interacting with modules: Helper Match This match (-m helper --helper name) allows selection of packets from connections monitored or created by the named helper. CT Target This target (-j CT --helper name ...) , introduced in the 3.4 kernels, allows for explicit association of a helper with a connection. It is important to note that the name used in iptables is not always the same as the name in the kernel module. Names used in iptables are shown in the following table: Name of kernel module Name recognized by iptables nf_conntrack_amanda amanda nf_conntrack_ftp ftp nf_conntrack_h323 RAS (udp 1719), Q.931 (tcp 1720) nf_conntrack_irc irc nf_conntrack_netbios_ns netbios-ns nf_conntrack_pptp pptp nf_conntrack_sane sane nf_conntrack_sip sip nf_conntrack_snmp snmp nf_conntrack_tftp tftp Netfilter helpers present an opportunity for attackers to attempt to breach your firewall by IP address spoofing; See https://home.regit.org/netfilter-en/secure-use-of-helpers/ for a description of the Netfilter facilities available to meet these attacks.
Shorewall Support for Helpers Shorewall includes support for helpers is several areas. These areas are covered in the sections below.
Module Loading Shorewall includes support for loading the helper modules as part of its support for loading kernel modules in general. There are several options in shorewall.conf (5) that deal with kernel module loading: MODULESDIR This option specifies a comma-separated list of directories where Shorewall will look for kernel modules to load. MODULE_SUFFIX Lists the possible suffixes for module names. LOAD_HELPERS_ONLY Controls whether Shorewall should load only the helpers and leave the other modules to the auto-loader. This option dramatically reduces the time to process a shorewall start or shorewall restart command. HELPERS This option was added in Shorewall 4.5.7 and lists the modules to be enabled for association with connections. This option is fully functional only on systems running kernel 3.5 or later. The module names allowed in this list are amanda, ftp, h323, irc, netbios-ns, pptp, sane, sip, snmp and tftp. AUTOHELPERS This option was also added in Shorewall 4.5.7. When enabled on systems that support the CT Target capability, it provides automatic association of helpers to connections in the same manner as in pre-3.5 kernels (and with the same vulnerabilities). The helper modules to be loaded are listed in the file /usr/share/shorewall/helpers. If you wish to customize that file to load only a subset of the helpers or to specify module parameters, then copy the file to /etc/shorewall/ and modify the copy. That way, your changes won't be overwritten the next time that Shorewall is updated on your system. On systems running a a kernel earlier than 3.5, not all of the helpers can be totally disabled. The following modules can be disabled by using the parameter ports=0 in /etc/shorewall/helpers: ftp irc sane sip tftp After disabling one or more helpers using this method, you must: Unload the related module(s). Restart Shorewall (use the -c option (e.g., shorewall restart -c) if you have AUTOMAKE=Yes in shorewall.conf (5)).. Note that if you choose to reboot your system to unload the modules, then if you have CT:helper entries in shorewall-conntrack (5) that refer to the module(s) and you have AUTOMAKE=Yes in shorewall.conf (5), then Shorewall will fail to start at boot time.
Iptables The iptables helper match is supported by Shorewall in the form of the HELPER column in shorewall-tcrules (5). The CT target is supported directly in shorewall-conntrack (5). In these files, Shorewall supports the same module names as iptables; see the table above. Beginning with Shorewall 4.5.7, there is a HELPER column in shorewall-rules (5). In the NEW section, this column allows the explicit association of a helper with connections allowed by a given rules. The column may contain any of the helper names recognized by iptables (see the table above). In the RELATED section, the rule will only match the packet if the related connection has the named helper attached. Also added in Shorewall 4.5.7 is the HELPER action in shorewall-rules (5). HELPER rules associate the helper listed in the HELPER column with connections that match the rule. A destination zone should not be specified in HELPER rules.
Capabilities The output of shorewall show capabilities has two entries for each of the helpers listed above that can be disabled by adding ports=0 in /etc/shorewall/helpers. shorewall show capabilities Amanda Helper: Available FTP Helper: Not available FTP-0 Helper: Available IRC Helper: Not available IRC-0 Helper: Available Netbios_ns Helper: Available H323 Helper: Not available PPTP Helper: Available SANE Helper: Not available SANE-0 Helper: Available SNMP Helper: Available TFTP Helper: Not available TFTP-0 Helper: Available iptables -S (IPTABLES_S): Available Basic Filter (BASIC_FILTER): Available CT Target (CT_TARGET): Available Kernel Version (KERNELVERSION): 30404 Capabilities Version (CAPVERSION): 40507 The above output is produced when this /etc/shorewall/helpers file is used on a system running kernel 3.4.4: loadmodule nf_conntrack_ftp ports=0 loadmodule nf_conntrack_irc ports=0 loadmodule nf_conntrack_netbios_ns loadmodule nf_conntrack_sip ports=0 loadmodule nf_conntrack_tftp ports=0 loadmodule nf_conntrack_sane ports=0 The reason for the double capabilities is that when ports=0 is specified, the iptables name of the helper gets '-0' added to it. So in order for the compiler to generate the correct iptables commands, it needs to know if ports=0 was specified for each of the helprs that support it. Notice that most of the other helpers are available, even though their modules were not loaded. That's because auto-loading occurs during capability detection on those modules whose iptables name matches the module name.
Kernel >= 3.5 and Shorewall >= 4.5.7 While the AUTOHELPER option described above provides for seamless migration to kernel 3.5 and beyond, we recommend setting AUTOHELPER=No at the first opportunity after migrating. Additionally, you should: Use the HELPER action and the HELPER column in shorewall-rules (5) to attach helpers to only those connections that you need to support. If you run one or more servers (such as an FTP server) that interact with helpers, you should consider adding rules to the RELATED section of shorewall-rules (5) to limit the scope of the helper. Suppose that your Linux FTP server is in zone dmz and has address 70.90.191.123. #ACTION SOURCE DEST PROTO DEST SOURCE # PORT(S) PORT(2) SECTION RELATED ACCEPT all dmz:70.90.191.123 32768: ; helper=ftp # passive FTP to dmz server; /proc/sys/net/ipv4/ip_local_port_range == 32760:65535 ACCEPT dmz:70.90.191.123 all tcp 1024: 20 ; helper=ftp # active FTP to dmz server ACCEPT loc,dmz,$FW net tcp - 1024: ; helper=ftp # passive FTP to net ACCEPT net all tcp 1024: 20 ; helper=ftp # active FTP from net DROP:info all all ; helper=ftp # SECTION NEW HELPER all net tcp 21 ; helper=ftp ACCEPT all dmz:70.90.191.123 tcp 21 ; helper=ftp
shorewall-docs-xml-4.5.21/template.xml0000644000175000017500000000211612222401136017551 0ustar teastepteastep
<authorgroup> <author> <firstname>Tom</firstname> <surname>Eastep</surname> </author> </authorgroup> <pubdate><?dbtimestamp format="Y/m/d"?></pubdate> <copyright> <year>2012</year> <holder>Thomas M. Eastep</holder> </copyright> <legalnotice> <para>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 <quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para> </legalnotice> </articleinfo> <section> <title/> <para/> </section> </article> ��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������shorewall-docs-xml-4.5.21/troubleshoot.xml����������������������������������������������������������0000644�0001750�0001750�00000054255�12222401136�020502� 0����������������������������������������������������������������������������������������������������ustar �teastep�������������������������teastep����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> <article id="usefull_links"> <!--$Id$--> <articleinfo> <title>Shorewall Troubleshooting Guide Tom Eastep 2001-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.
<quote>shorewall start</quote> and <quote>shorewall restart</quote> Errors If the error is detected by the Shorewall compiler, it should be fairly obvious where the problem was found. Each error message includes the configuration file name and line number where the error was detected and often gives the particular item in error. The item is either enclosed in parentheses or is at the end following a colon (":"). Example:gateway:~/test # shorewall restart . Compiling... ERROR: Invalid ICMP Type (0/400) : /root/test/rules (line 19) gateway:~/test # In this case, line 19 in the rules file specified an invalid ICMP Type (0/400). Additional information about the error can be obtained using the 'debug' keyword (Shorewall 4.4.19 and earlier) or using the (-T) option. Example (4.4.19 and earlier): gateway:~/test # shorewall debug restart Compiling... ERROR: Invalid ICMP Type (0/400) : /root/test/rules (line 19) at /usr/share/shorewall/Shorewall/Config.pm line 338 Shorewall::Config::fatal_error('Invalid ICMP Type (0/400)') called at /usr/share/shorewall/Shorewall/Chains.pm line 885 Shorewall::Chains::validate_icmp('0/400') called at /usr/share/shorewall/Shorewall/Chains.pm line 949 Shorewall::Chains::do_proto('icmp', '0/400', '-') called at /usr/share/shorewall/Shorewall/Rules.pm line 1055 Shorewall::Rules::process_rule1('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall/Shorewall/Rules.pm line 1290 Shorewall::Rules::process_rule('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall/Shorewall/Rules.pm line 1336 Shorewall::Rules::process_rules() called at /usr/share/shorewall/Shorewall/Compiler.pm line 799 Shorewall::Compiler::compiler('/var/lib/shorewall/.restart', '/root/test', 0, 4) called at /usr/share/shorewall/compiler.pl line 86 gateway:~/test # Example (4.4.20 and later): gateway:~/test # shorewall restart -T Compiling... ERROR: Invalid ICMP Type (0/400) : /root/test/rules (line 19) at /usr/share/shorewall/Shorewall/Config.pm line 338 Shorewall::Config::fatal_error('Invalid ICMP Type (0/400)') called at /usr/share/shorewall/Shorewall/Chains.pm line 885 Shorewall::Chains::validate_icmp('0/400') called at /usr/share/shorewall/Shorewall/Chains.pm line 949 Shorewall::Chains::do_proto('icmp', '0/400', '-') called at /usr/share/shorewall/Shorewall/Rules.pm line 1055 Shorewall::Rules::process_rule1('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall/Shorewall/Rules.pm line 1290 Shorewall::Rules::process_rule('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall/Shorewall/Rules.pm line 1336 Shorewall::Rules::process_rules() called at /usr/share/shorewall/Shorewall/Compiler.pm line 799 Shorewall::Compiler::compiler('/var/lib/shorewall/.restart', '/root/test', 0, 4) called at /usr/share/shorewall/compiler.pl line 86 gateway:~/test # This information is useful to Shorewall support if you need to file a problem report. The end of the compile phase is signaled by a message such as the following:Shorewall configuration compiled to /var/lib/shorewall/.restartErrors occurring past that point are said to occur at run-time because they occur during the running of the compiled firewall script (/var/lib/shorewall/.restart in the case of the above message). One common run-time failure is that the iptables-restore program encounters an error. This will produce an error such as the following:... Restarting Shorewall.... iptables-restore v1.3.6: No chain/target/match by that name Error occurred at line: 83 Try `iptables-restore -h' or 'iptables-restore --help' for more information. ERROR: iptables-restore Failed. Input is in /var/lib/shorewall/.iptables-restore-input Restoring Shorewall... Shorewall restored from /var/lib/shorewall/restore Terminated gateway:~/test # A look at /var/lib/shorewall/restore at line 83 might show something like the following:-A reject -p tcp -j REJECT --reject-with tcp-resetIn this case, the user had compiled his own kernel and had forgotten to include REJECT target support (see kernel.htm). 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 compiler. debug causes altered behavior of generated scripts. 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. In other run-time failure cases: Make a note of the error message that you see. shorewall debug start 2> /tmp/trace Look at the /tmp/trace file and see if that helps you determine what the problem is. Be sure you find the place in the log where the error message you saw is generated -- you should find the message near the end of the log. If you still can't determine what's wrong then see the support page.
Your Network Environment Many times when people have problems with Shorewall, the problem is actually an ill-conceived network setup. Here are several popular snafus: Port Forwarding where client and server are in the same subnet. See FAQ 2. Trying to test net->loc DNAT rules from inside your firewall. You must test these rules from outside your firewall. Multiple interfaces connected to the same HUB or Switch. Given the way that the Linux kernel respond to ARP who-has requests, this type of setup does NOT work the way that you expect it to. 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.
New Device Doesn't Work? If you have just added a new device such as VOIP and it doesn't work, be sure that you have assigned it an IP address in your local network and that its default gateway has been set to the IP address of your internal interface. For many of these devices, the simplest solution is to run a DHCP server; running it on your firewall is fine — be sure to set the dhcp option on your internal interface in /etc/shorewall/interfaces.
Connection Problems One very important thing to remember is that not all connection problems are Shorewall configuration problems. If the connection that is giving you problems is to or from the firewall system or if it doesn't rely on NAT or Proxy ARP then you can often eliminate Shorewall using a simple test: /sbin/shorewall clear Try the connection. If it works then the problem is in your Shorewall configuration; if the connection still doesn't work then the problem is not with Shorewall or the way that it is configured. Be sure to /sbin/shorewall start after the test. If you still suspect Shorewall and the appropriate policy for the connection that you are trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING TO MAKE IT WORK. Such additional rules will NEVER make it work, they add clutter to your rule set and they represent a big security hole in the event that you forget to remove them later. I also recommend against setting all of your policies to ACCEPT in an effort to make something work. That robs you of one of your best diagnostic tools - the Shorewall messages that Netfilter will generate when you try to connect in a way that isn't permitted by your rule set. Check your log (/sbin/shorewall show log). If you don't see Shorewall messages, then your problem is probably NOT a Shorewall problem. If you DO see packet messages, it may be an indication that you are missing one or more rules -- see FAQ 17. While you are troubleshooting, it is a good idea to clear two variables in /etc/shorewall/shorewall.conf: LOGRATE= LOGBURST=""This way, you will see all of the log messages being generated (be sure to restart shorewall after clearing these variables). Log Message Jun 27 15:37:56 gateway kernel: Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 LEN=47 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 (see FAQ 17). IN=eth2 - the packet entered the firewall via eth2 OUT=eth1 - if accepted, the packet would be sent on eth1 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 - 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: #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT dmz loc udp 53
Ping Problems Either can't ping when you think you should be able to or are able to ping when you think that you shouldn't be allowed? Shorewall's Ping Management is described here. Here are a couple of tips: Remember that Shorewall doesn't automatically allow ICMP type 8 (ping) requests to be sent between zones. If you want pings to be allowed between zones, you need a rule of the form: #ACTION SOURCE DEST PROTO DEST # PORT(S) Ping(ACCEPT)<source zone> <destination zone> The ramifications of this can be subtle. For example, if you have the following in /etc/shorewall/nat: #EXTERNAL INTERFACE INTERNAL 10.1.1.2 eth0 130.252.100.18 and you ping 130.252.100.18, unless you have allowed icmp type 8 between the zone containing the system you are pinging from and the zone containing 10.1.1.2, the ping requests will be dropped. Ping requests are subject to logging under your policies. So ping floods can cause an equally big flood of log messages. To eliminate these, as the last rule in your /etc/shorewall/rules file add: #ACTION SOURCE DEST PROTO DEST # PORT(S) Ping(DROP)net all
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.
Other Gotchas Seeing rejected/dropped packets logged out of the INPUT or FORWARD chains? This means that: your zone definitions are screwed up and the host that is sending the packets or the destination host isn't in any zone (using an /etc/shorewall/hosts file are you?); or the source and destination hosts are both connected to the same interface and you don't have a policy or rule for the source zone to or from the destination zone or you haven't set the routeback option for the interface in /etc/shorewall/interfaces. You have connected two firewall interfaces (from different zones) to the same hub or switch. If you specify routefilter for an interface, that interface must be up prior to starting the firewall. Is your routing correct? For example, internal systems usually need to be configured with their default gateway set to the IP address of their nearest firewall interface. One often overlooked aspect of routing is that in order for two hosts to communicate, the routing between them must be set up in both directions. So when setting up routing between A and B, be sure to verify that the route from B back to A is defined and correct. Do you have your kernel properly configured? Click here to see kernel configuration information.
Still Having Problems? See the Shorewall Support Page.
shorewall-docs-xml-4.5.21/survey-200603.xml0000644000175000017500000005076612222401136020041 0ustar teastepteastep
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-4.5.21/shorewall_extension_scripts.xml0000644000175000017500000005362512222401136023614 0ustar teastepteastep
Extension Scripts Tom Eastep 2001-2010 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.
Extension Scripts Extension scripts are user-provided scripts that are invoked at various points during firewall start, restart, stop and clear. The scripts are placed in /etc/shorewall and are processed using the Bourne shell source mechanism. Be sure that you actually need to use an extension script to do what you want. Shorewall has a wide range of features that cover most requirements. DO NOT SIMPLY COPY RULES THAT YOU FIND ON THE NET INTO AN EXTENSION SCRIPT AND EXPECT THEM TO WORK AND TO NOT BREAK SHOREWALL. TO USE SHOREWALL EXTENSION SCRIPTS YOU MUST KNOW WHAT YOU ARE DOING WITH RESPECT TO iptables/Netfilter AND SHOREWALL. The following scripts can be supplied: lib.private -- Intended to contain declarations of shell functions to be called by other run-time extension scripts. See this article for an example of its use. compile -- Invoked by the rules compiler early in the compilation process. Must be written in Perl. init -- invoked early in shorewall start and shorewall restart initdone -- invoked after Shorewall has flushed all existing rules but before any rules have been added to the builtin chains. start -- invoked after the firewall has been started or restarted. started -- invoked after the firewall has been marked as 'running'. stop -- invoked as a first step when the firewall is being stopped. stopped -- invoked after the firewall has been stopped. clear -- invoked after the firewall has been cleared. tcclear -- invoked to clear traffic shaping when CLEAR_TC=Yes in shorewall.conf. refresh -- called in place of init when the firewall is being refreshed rather than started or restarted. refreshed -- invoked after the firewall has been refreshed. maclog -- invoked while mac filtering rules are being created. It is invoked once for each interface having 'maclist' specified and it is invoked just before the logging rule is added to the current chain (the name of that chain will be in $CHAIN). isusable -- invoked when Shorewall is trying to determine the usability of the network interface associated with an optional entry in /etc/shorewall/providers. $1 is the name of the interface which will have been determined to be up and configured before the script is invoked. The return value from the script indicates whether or not the interface is usable (0 = usable, other = unusable). Example:# Ping a gateway through the passed interface case $1 in eth0) ping -c 4 -t 1 -I eth0 206.124.146.254 > /dev/null 2>&1 return ;; eth1) ping -c 4 -t 1 -I eth1 192.168.12.254 > /dev/null 2>&1 return ;; *) # No additional testing of other interfaces return 0 ;; esac We recommend that this script only be used with ADMINISABSENTMINDED=Yes. The firewall state when this script is invoked is indeterminate. So if you have ADMINISABSENTMINDED=No in shorewall.conf(8) and output on an interface is not allowed by routestopped(8) then the isuasable script must blow it's own holes in the firewall before probing. save -- This script is invoked during execution of the shorewall save and shorewall-lite save commands. restored -- This script is invoked at the completion of a successful shorewall restore and shorewall-lite restore. findgw -- This script is invoked when Shorewall is attempting to discover the gateway through a dynamic interface. The script is most often used when the interface is managed by dhclient which has no standardized location/name for its lease database. Scripts for use with dhclient on several distributions are available at http://www.shorewall.net/pub/shorewall/contrib/findgw/ scfilter -- Added in Shorewall 4.4.14. Unlike the other scripts, this script is executed by the command-line tools (/sbin/shorewall, /sbin/shorewall6, etc) and can be used to reformat the output of the show connections command. The connection information is piped through this script so that the script can drop information, add information or alter the format of the information. When using Shorewall Lite or Shorewall6 Lite, the script is encapsulated in a function that is copied into the generated auxillary configuration file. That function is invoked by the 'show connections' command. The default script is as follows and simply pipes the output through unaltered. #! /bin/sh cat - If your version of Shorewall doesn't have the file that you want to use from the above list, you can simply create the file yourself. You can also supply a script with the same name as any of the filter chains in the firewall and the script will be invoked after the /etc/shorewall/rules file has been processed but before the /etc/shorewall/policy file has been processed. The following table indicate which commands invoke the various scripts. script Commands clear clear compile check, compile, export, load, refresh, reload, restart, restore,start continue init load, refresh, reload, restart restore, start initdone check, compile, export, refresh, restart, start isusable refresh, restart, restore, start maclog check, compile, export, refresh, restart, start refresh refresh refreshed refresh restored restore save save scfilter show connections start load, reload, restart, start started load, reload, restart, start stop stop, clear stopped stop, clear tcclear load, reload, restart, restore, start There are a couple of special considerations for commands in extension scripts: When you want to run iptables, use the command run_iptables instead. run_iptables will run the iptables utility passing the arguments to run_iptables and if the command fails, the firewall will be stopped (or restored from the last save command, if any). run_iptables should not be called from the started or restored scripts. If you wish to generate a log message, use log_rule_limit. Parameters are: Log Level Chain to insert the rule into Chain name to display in the message (this can be different from the preceding argument — see the Port Knocking article for an example of how to use this). Disposition to report in the message (ACCEPT, DROP, etc) Rate Limit (if passed as "" then $LOGLIMIT is assumed — see the LOGLIMIT option in /etc/shorewall/shorewall.conf) Log Tag ("" if none) Command (-A or -I for append or insert). The remaining arguments are passed "as is" to iptables Many of the extension scripts get executed for both the shorewall start and shorewall restart commands. You can determine which command is being executed using the contents of $COMMAND. if [ $COMMAND = start ]; then ... In addition to COMMAND, Shorewall defines three other variables that may be used for locating Shorewall files: CONFDIR - The configuration directory. Will be /etc/shorewall, /etc/shorewall6/, /etc/shorewall-lite, or /etc/shorewall6-lite depending on which product is running. SHAREDIR - The product shared directory. Will be /usr/share/shorewall, /usr/share/shorewall6/, /usr/share/shorewall-lite, or /usr/share/shorewall6-lite depending on which product is running. VARDIR - The product state directory. Defaults /usr/share/shorewall, /usr/share/shorewall6/, /usr/share/shorewall-lite, or /usr/share/shorewall6-lite depending on which product is running, but may be overridden by an entry in ${CONFDIR}/vardir.
Compile-time vs Run-time Scripts Shorewall runs some extension scripts at compile-time rather than at run-time. The following table summarizes when the various extension scripts are run: Compile-time Run-time compile clear initdone init maclog isusable Per-chain (including those associated with actions) start started stop stopped tcclear refresh refreshed restored scfilter Compile-time extension scripts are executed using the Perl 'eval `cat <file>`' mechanism. Be sure that each script returns a 'true' value; otherwise, the compiler will assume that the script failed and will abort the compilation. Each compile-time script is implicitly prefaced with: package Shorewall::User; Most scripts will need to begin with the following line:use Shorewall::Chains;For more complex scripts, you may need to 'use' other Shorewall Perl modules -- browse /usr/share/shorewall/Shorewall/ to see what's available. When a script is invoked, the $chainref scalar variable will hold a reference to a chain table entry. $chainref->{name} contains the name of the chain $chainref->{table} holds the table name To add a rule to the chain:add_rule( $chainref, <the rule> [ , <break lists> ] );Where <the rule> is a scalar argument holding the rule text. Do not include "-A <chain name>" Example:add_rule( $chainref, '-j ACCEPT' ); The add_rule() function accepts an optional third argument; If that argument evaluates to true and the passed rule contains a --dports or --sports list with more than 15 ports (a port range counts as two ports), the rule will be split into multiple rules where each resulting rule has 15 or fewer ports in its --dports and --sports lists. To insert a rule into the chain: insert_rule( $chainref, <rulenum>, <the rule> );The log_rule_limit() function works like it did in the shell compiler with three exceptions: You pass the chain reference rather than the name of the chain. The commands are 'add' and 'insert' rather than '-A' and '-I'. There is only a single "pass as-is to iptables" argument (so you must quote that part). Example:log_rule_limit( 'info' , #Log Level $chainref , #Chain to add the rule to $chainref->{name}, #Name of the chain as it will appear in the log prefix 'DROP' , #Disposition of the packet '', #Limit '' , #Log tag 'add', #Command '-p tcp' #Added to the rule as-is );Note that in the 'initdone' script, there is no default chain ($chainref). You can obtain a reference to a standard chain by:my $chainref = $chain_table{<table>}{<chain name>};Example:my $chainref = $chain_table{filter}{INPUT}; You can also use the hash references $filter_table, $mangle_table and $nat_table to access chain references in the three main tables. Example: my $chainref = $filter_table->{INPUT}; #Same as above with a few less keystrokes; runs faster too For imformation about the 'compile' extension script, see the Manual Chains article.
shorewall-docs-xml-4.5.21/NAT.xml0000644000175000017500000002535112222401136016366 0ustar teastepteastep
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 ALL INTERFACES 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 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 DEST SOURCE ORIG # PORT(S) PORT(S) DEST 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-4.5.21/traffic_shaping.xml0000644000175000017500000032302712222401136021074 0ustar teastepteastep
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/tcrules file. 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/tcrules 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/tcrules) is assigned. Netfilter also supports a mark value on each connection. You can assign connection mark values in /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/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. 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 #INTERFACE IN-BANDWITH OUT-BANDWIDTH ppp0 6000kbit 500kbit
/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 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 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 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-tcdevices (5) for a description of the allowable codloptions.
/etc/shorewall/tcrules 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 tcrules file is not stateful. So every packet that goes into, out of or through your firewall is subject to entries in the tcrules file. Because tcrules 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/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). Columns in the file are as follows: ACTION - ACTION (previously called MARK) specifies the mark value is to be assigned in case of a match. This is an integer in the range 1-255 (1-16383 if you set WIDE_TC_MARKS=Yes or TC_BITS=14 in shorewall.conf (5) ). 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. This value may be optionally followed by : and either F, P or "T" to designate that the marking will occur in the FORWARD, PREROUTING or POSTROUTING chains respectively. If this additional specification is omitted, the chain used to mark packets will be determined as follows: If the SOURCE is $FW[:<address>], then the rule is inserted in the OUTPUT chain. Otherwise, the chain is determined by the setting of the MARK_IN_FORWARD_CHAIN option in shorewall.conf. Use the 'T' qualifier if you want the rule to apply equally to traffic being routed through the firewall and to traffic originating on the firewall itself. Normally, the mark is applied to the packet. If you follow the mark value with ":" and "C", then the mark is applied to the connection. "C" can be combined with "F", "P" or "T" to designate that the connection should be marked in a particular chain (e.g., "CF", "CP", "CT"). There are additional special values available: RESTORE[/mask] -- restore the packet's mark from the connection's mark using the supplied mask if any. Your kernel and iptables must include CONNMARK support. As above, may be followed by :P, :F or :T. SAVE[/mask] -- save the packet's mark to the connection's mark using the supplied mask if any. Your kernel and iptables must include CONNMARK support. As above, may be followed by :P, :F or :T. CONTINUE Don't process any more marking rules in the table. As above, may be followed by :P, :F or :T. COMMENT -- the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries. The comment will appear delimited by "/* ... */" in the output of shorewall show mangle To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. To use CLASSIFY, your kernel and iptables must include CLASSIFY target support. In that case, this column contains a classification (classid) of the form <major>:<minor> where <major> and <minor> are integers. Corresponds to the 'class' specification in these traffic shaping modules: atm cbq dsmark pfifo_fast htb prio Classification occurs in the POSTROUTING chain except when the SOURCE contains $FW[:<address>] in which case, the classify action takes place in the OUTPUT chain. When used with the builtin traffic shaper, the <major> class is the interface number and the <minor> class is either: Constructed by Shorewall. The method of construction depends on the setting of WIDE_TC_MARKS (TC_BITS in shorewall 4.4.26 and later) in (shorewall.conf (5)). When WIDE_TC_MARKS=No (the default) or TC_BITS > 14, the <minor> class is: the MARK value of the class preceded by the number "1" or "10" (MARK value 1 is <minor> class 11, MARK value 22 is <minor> class 122, and so on). "10" is used where there are more than 10 devices defined in /etc/shorewall/tcdevices. When WIDE_TC_MARKS=Yes (TC_BITS >= 14), the <minor> class is assigned sequentially beginning with 2. The class number, if specified. SOURCE - Source of the packet. May be: An interface name - matches traffic entering the firewall on the specified interface. May not be used in classify rules or in rules using the :T chain qualifier. A comma-separated list of host or network IP addresses or MAC addresses. This form will not match traffic that originates on the firewall itself unless either <major><minor> or the :T chain qualifier is used in the ACTION column. Examples: 0.0.0.0/0 192.168.1.0/24, 172.20.4.0/24 An interface name followed by a colon (":") followed by a comma-separated list of host or network IP addresses or MAC addresses. May not be used in classify rules or in rules using the :T chain qualifier. $FW optionally followed by a colon (":") and a comma-separated list of host or network IP addresses. matches packets originating on the firewall. May not be used with a chain qualifier (:P, :F, etc.) in the ACTION column. MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 If your kernel includes iprange match support, then address ranges may be included in the address lists. DEST - Destination of the packet. May be: An interface name. May not be used in the PREROUTING chain (:P in the mark column or no chain qualifier and MARK_IN_FORWARD_CHAIN=No in shorewall.conf (5)). The interface name may be optionally followed by a colon (":") and an IP address list. A comma-separated list of host or network IP addresses. The list may include ip address ranges if your kernel and iptables include iprange support. PROTO - Protocol - Must be "tcp", "udp", "icmp", "ipp2p", "ipp2p:udp", "ipp2p:all" a number, or "all". "ipp2p" requires ipp2p match support in your kernel and iptables. PORT(S) - Destination Ports. A comma-separated list of Port names (from /etc/services), port numbers or port ranges; if the protocol is "icmp", this column is interpreted as the destination icmp-type(s). If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example "bit" for bit-torrent). If no PORT is given, "ipp2p" is assumed. Note that the xtables-addons version of IPP2P does not support the "ipp2p" option; if the column is empty or contains "ipp2p" when using that version of IPP2P, Shorewall will substitute "edk,kazaa,gnu,dc". This column is ignored if PROTOCOL = all but must be entered if any of the following field is supplied. In that case, it is suggested that this field contain "-" CLIENT PORT(S) - (Optional) Port(s) used by the client. If omitted, any source port is acceptable. Specified as a comma-separate list of port names, port numbers or port ranges. USER/GROUP (Optional) This column may only be non-empty if the SOURCE is the firewall itself. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group. It may contain : [!][<user name or number>]:[<group name or number>][+<program name>] The colon is optional when specifying only a user. Examples: joe #program must be run by joe :kids #program must be run by a member of the 'kids' group !:kids #program must not be run by a member of the 'kids' group +upnpd #program named upnpd (This feature was removed from Netfilter in kernel version 2.6.14). TEST (Optional) Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. Tests have the format [!]<value>[/<mask>][:C] Where: ! Inverts the test (not equal) <value> Value of the packet or connection mark. <mask> A mask to be applied to the mark before testing :C Designates a connection mark. If omitted, the packet mark's value is tested. LENGTH (Optional) This field, if present, allows you to match the length of a packet against a specific value or range of values. A range is specified in the form <min>:<max> where either <min> or <max> (but not both) may be omitted. If <min> is omitted, then 0 is assumed; if <max> is omitted, than any packet that is <min> or longer will match. You must have iptables length support for this to work. If you let it empty or place an "-" here, no length match will be done. Examples: 1024, 64:1500, :100 TOS (Optional) Type of Service. Either a standard name, or a numeric value to match.
Minimize-Delay (16) Maximize-Throughput (8) Maximize-Reliability (4) Minimize-Cost (2) Normal-Service (0)
HELPER (Optional). Names one of the Netfilter protocol helper modules such as ftp, sip, amanda, etc. HEADERS (Optioinal, Shorewall6 only, added in Shorewall 4.4.15). List of IPv6 headers that may appear in packets. See shorewall6-tcrules (5) for details.
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. #ACTION SOURCE DESTINATION PROTOCOL PORT(S) 1 eth1 0.0.0.0/0 all 2 eth2 0.0.0.0/0 all 2 eth3 0.0.0.0/0 all 3 $FW 0.0.0.0/0 all All GRE (protocol 47) packets destined for 155.186.235.151 should be marked with 12. #ACTION SOURCE DESTINATION PROTOCOL PORT(S) 12:T 0.0.0.0/0 155.182.235.151 47 All SSH request packets originating in 192.168.1.0/24 and destined for 155.186.235.151 should be marked with 22. #ACTION SOURCE DESTINATION PROTOCOL PORT(S) 22:T 192.168.1.0/24 155.182.235.151 tcp 22 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. #ACTION SOURCE DESTINATION PROTOCOL PORT(S) CLIENT # PORT(S) 1:110 0.0.0.0/0 0.0.0.0/0 tcp 22 1:110 0.0.0.0/0 0.0.0.0/0 tcp - 22 Mark all ICMP echo traffic with packet mark 1. Mark all peer to peer traffic with packet mark 4. 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. #ACTION SOURCE DESTINATION PROTOCOL PORT(S) CLIENT USER/ TEST # PORT(S) GROUP 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request 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 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 The last four rules can be translated as:
"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."
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). #ACTION SOURCE DESTINATION PROTOCOL PORT(S) CLIENT USER/ TEST CONNBYTES TOS HELPER # PORT(S) GROUP 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
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 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/tcrules to be validated against the TC configuration. In this configuration, it is Shorewall that controls TC configuration (except for IPv6 tcrules). 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/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/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
tcrules file #ACTION SOURCE DEST PROTO PORT(S) CLIENT USER # PORT(S) 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 # mark traffic which should have a lower priority with a 3: # mldonkey 3 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 tcrules file: 3 192.168.1.128/25 0.0.0.0/0 all 3 192.168.3.28 0.0.0.0/0 all 3 0.0.0.0/0 60.0.0.0/24 all 3 0.0.0.0/0 0.0.0.0/0 udp 6662,6663 3 0.0.0.0/0 0.0.0.0/0 udp - 6662,6663 3 0.0.0.0/0 0.0.0.0/0 tcp 6662,6663 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.
tcrules file #ACTION SOURCE DEST PROTO PORT(S) CLIENT USER # PORT(S) 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:CLASS MARK RATE: CEIL PRIORITY OPTIONS # DMAX:UMAX 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/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-tcrules(5) with the following key exceptions: The first match determines the classification, whereas in the tcrules 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 DEST SOURCE ORIGINAL # PORT(S) PORT(S) DEST 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 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. DEST PORT(S) 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. SOURCE PORT 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 REDIRECTED # INTERFACES 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 DEST SOURCE #CLASS PORT(S) PORT(S) # # 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/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/tcrules.
Testing Tools At least one Shorewall user has found this tool helpful: http://e2epi.internet2.edu/network-performance-toolkit.html
shorewall-docs-xml-4.5.21/Shorewall-init.xml0000644000175000017500000002365512222401136020652 0ustar teastepteastep
Shorewall Init Tom Eastep 2010 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 The Shorewall init scripts released from shorewall.net and by most distributions start Shorewall after networking. This allows Shorewall to detect the network configuration and taylor itself accordingly. It is possible to start Shorewall prior to networking but doing so limits the set of Shorewall features that can be used. When Shorewall starts after networking, there is the possibility of unwanted connections being accepted between the time that an interface comes up and the time that Shorewall has finished starting up. Also, Shorewall has had no means of reacting when interfaces are brought up and down. Beginning with Shorewall 4.4.10, a new package, Shorewall Init, is available. Shorewall Init serves two purposes: It can 'close' the firewall before the network interfaces are brought up during boot. It can change the firewall state as the result of interfaces being brought up or taken down. These two features can be controlled independently. Shorewall Init can be used together with any combination of the other Shorewall packages. Shorewall-init works on RedHat-based, SuSE-based and Debian-based distributions.
Closing the Firewall before the Network Interfaces are brought up When Shorewall-init is first installed, it does nothing until you configure it. The configuration file is /etc/default/shorewall-init on Debian-based systems and /etc/sysconfig/shorewall-init otherwise. There are two settings in the file: PRODUCTS Lists the Shorewall packages that you want to integrate with Shorewall-init. Example: PRODUCTS="shorewall shorewall6" IFUPDOWN When set to 1, enables integration with NetworkManager and the ifup/ifdown scripts. To close your firewall before networking starts: In the Shorewall-init configuration file, set PRODUCTS to the firewall products installed on your system. Be sure that your current firewall script(s) (normally in /var/lib/<product>/firewall) is(are) compiled with the 4.4.10 compiler. Shorewall and Shorewall6 users can execute these commands: shorewall compile shorewall6 compile Shorewall-lite and Shorewall6-lite users can execute these commands on the administrative system: shorewall export firewall-name-or-ip-address shorewall6 export firewall-name-or-ip-address That's all that is required.
Integration with NetworkManager and ifup/ifdown Scripts To integrate with NetworkManager and ifup/ifdown, additional steps are required. You probably don't want to enable this feature if you run a link status monitor like swping or LSM. In the Shorewall-init configuration file, set IFUPDOWN=1. In your Shorewall interfaces file(s), set the option on any interfaces that must be up in order for the firewall to start. At least one interface must have the or option if you perform the next optional step. Optional) -- If you have specified at least one or interface, you can then disable automatic firewall startup at boot time. On Debian systems, set startup=0 in /etc/default/product. On other systems, use your service startup configuration tool (chkconfig, insserv, ...) to disable startup. If your system uses Upstart as it's system initialization daemon, you should not disable startup. Upstart is standard on recent Ubuntu and Fedora releases and is optional on Debian. The following actions occur when an interface comes up: FIREWALL STATE INTERFACE ACTION Any Required start stopped Optional start started Optional enable started Any restart The following actions occur when an interface goes down: FIREWALL STATE INTERFACE ACTION Any Required stop stopped Optional start started Optional disable started Any restart For optional interfaces, the /var/lib/product/interface.state files are maintained to reflect the state of the interface so that they may be used by the standard isusable script. Please note that the action is carried out using the current compiled script; the configuration is not recompiled. A new option has been added to shorewall.conf and shorewall6.conf. The REQUIRE_INTERFACE option determines the outcome when an attempt to start/restart/restore/refresh the firewall is made and none of the optional interfaces are available. With REQUIRE_INTERFACE=No (the default), the operation is performed. If REQUIRE_INTERFACE=Yes, then the operation fails and the firewall is placed in the stopped state. This option is suitable for a laptop with both ethernet and wireless interfaces. If either come up, the firewall starts. If neither comes up, the firewall remains in the stopped state. Similarly, if an optional interface goes down and there are no optional interfaces remaining in the up state, then the firewall is stopped. On Debian-based systems, during system shutdown the firewall is opened prior to network shutdown (/etc/init.d/shorewall stop performs a 'clear' operation rather than a 'stop'). This is required by Debian standards. You can change this default behavior by setting SAFESTOP=1 in /etc/default/shorewall (/etc/default/shorewall6, ...).
shorewall-docs-xml-4.5.21/QOSExample.xml0000644000175000017500000003777612222401136017740 0ustar teastepteastep
QOS Configuration 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 This configuration was inspired by the one in this thread on the OpenWRT Forum: https://forum.openwrt.org/viewtopic.php?pid=154533#p154533. The configuration has been adapted to Shorewall 4.5.6 with the following changes: The configuration uses an IFB, yet only uses firewall marks in the OUTPUT and FORWARD chains to classify packets; clearly that doesn't work To be more precise, it doesn't work with an unpatched kernel. The OpenWRT script assumes an 'act_conntrack' patch which performs conntrack processing on packets before they are sent to the IFB. That patch is not generally available. The configuration presented here uses U32 classifiers (shorewall-tcfilters(5)) to classify traffic for download shaping and uses the POSTROUTING chain for upload shaping. The sample uses a weak form of P2P classification; the one presented below uses IPP2P. The OpenWRT script assumed that the uplink was ATM -- the one below makes no assumption (it specifies 'ethernet' with overhead '0').
/etc/shorewall/params The shell variables set in the OpenWRT script are set in the Shorewall params file: DOWNLOAD=40000 #download speed in kbit. set xx% of real download speed UPLOAD=7000 # set xx% of real upload speed # multiports = up to 15 ports # ports to be classified as bulk #set after connection mark save and after connection mark restore TCP_BULK="1024:" #S and D ports UDP_BULK="1024:" #S and D ports # Destination ports to be classified as P2P TCP_P2P="13769" #D ports UDP_P2P="13769" #D ports IP_P2P="192.168.0.133" # Destination ports to be classified as normal TCP_NORMAL="80,443,25,20,21,110,993,995" # D ports UDP_NORMAL="" # Destination ports to be classified as Prio (overules bulk ports) TCP_PRIO="22,53" #destination ports UDP_PRIO="22,53" #destination ports # Destination ports to be classified as VoIP (overules bulk ports) TCP_VOIP="" UDP_VOIP="18080" IP_VOIP="192.168.0.226" #destination and source IP IP_VOIP="192.168.0.226" #destination and source IP #!!!!!uplink leaf class parameters!!!!!!!!! #bulk UP_LS_BULK_RATE=$(($UPLOAD*5/100)) UP_UL_BULK_RATE=$UPLOAD #settings leaf qdisc UP_BULK_RED_PROB=0.05 #red drob probability UP_BULK_RED_min=6250 #real limit. To limit BULK traffic UP_BULK_RED_min2=6250 #min for doing the calculations (burst and etc) UP_BULK_RED_max=$((2 * $UP_BULK_RED_min2 + $UP_BULK_RED_min)) UP_BULK_RED_burst=$(((5 * $UP_BULK_RED_min2) / (3 * 1000))) UP_BULK_RED_limit=$(($UP_BULK_RED_max * 5)) #P2P UP_LS_P2P_RATE=$(($UPLOAD * 5 / 100)) UP_UL_P2P_RATE=$UPLOAD #settings leaf qdisc UP_P2P_RED_PROB=0.05 #red drob probability UP_P2P_RED_min=32000 #real limit. To limit P2P traffic UP_P2P_RED_min2=32000 #min for doing the calculations (burst and etc) UP_P2P_RED_max=$((5 * $UP_P2P_RED_min2 + $UP_P2P_RED_min)) UP_P2P_RED_burst=$(((5 * $UP_P2P_RED_min2) / (3 * 1000))) UP_P2P_RED_limit=$(($UP_P2P_RED_max * 5)) #normal class UP_LS_NORMAL_RATE=$(($UPLOAD * 40 / 100)) UP_UL_NORMAL_RATE=$UPLOAD #settings leaf qdisc UP_NORMAL_RED_PROB=0.05 #red drob probability UP_NORMAL_RED_min=6250 #real limit. To limit NORMAL traffic UP_NORMAL_RED_min2=6250 #min for doing the calculations (burst and etc) UP_NORMAL_RED_max=$((2 * $UP_NORMAL_RED_min2 + $UP_NORMAL_RED_min)) UP_NORMAL_RED_burst=$(((5 * $UP_NORMAL_RED_min2) / (3 * 1000))) UP_NORMAL_RED_limit=$(($UP_NORMAL_RED_max * 5)) #prio UP_LS_PRIO_RATE=$(($UPLOAD*50/100)) UP_RT_PRIO_RATE="200" #rate in kbit UP_RT_PRIO_UMAX="400" #lengte of the packets [byte] UP_RT_PRIO_DMAX="15" #delay in ms UP_UL_PRIO_RATE=$UPLOAD #Voip UP_UL_VOIP_RATE=$UPLOAD UP_SC_VOIP_RATE="200" UP_SC_VOIP_UMAX="350" #length of the voip packets [byte] UP_SC_VOIP_DMAX="10" #delay in ms #bulk DOWN_LS_BULK_RATE=$(($DOWNLOAD*5/100)) DOWN_UL_BULK_RATE=$DOWNLOAD #leaf qdisc parameters DOWN_BULK_RED_PROB=0.05 #red drob probability DOWN_BULK_RED_min=62500 #real limit. To limit BULK traffic DOWN_BULK_RED_min2=62500 #min for doing the calculations (burst and etc) DOWN_BULK_RED_max=$((2 * $DOWN_BULK_RED_min2 + $DOWN_BULK_RED_min)) DOWN_BULK_RED_burst=$(((5 * $DOWN_BULK_RED_min2) / (3 * 1000))) DOWN_BULK_RED_limit=$(($DOWN_BULK_RED_max * 5)) #P2P DOWN_LS_P2P_RATE=$(($DOWNLOAD*5/100)) DOWN_UL_P2P_RATE=4000 #leaf qdisc parameters DOWN_P2P_RED_PROB=0.05 #red drob probability DOWN_P2P_RED_min=200000 #real limit. To limit P2P traffic DOWN_P2P_RED_min2=200000 #min for doing the calculations (burst and etc) DOWN_P2P_RED_max=$((2 * $DOWN_P2P_RED_min2 + $DOWN_P2P_RED_min)) DOWN_P2P_RED_burst=$(((5 * $DOWN_P2P_RED_min2) / (3 * 1000))) DOWN_P2P_RED_limit=$(($DOWN_P2P_RED_max * 5)) #normal class DOWN_LS_NORMAL_RATE=$(($DOWNLOAD*75/100)) DOWN_UL_NORMAL_RATE=$DOWNLOAD #leaf qdisc parameters DOWN_NORMAL_RED_PROB=0.05 #red drob probability DOWN_NORMAL_RED_min=62500 #real limit. To limit NORMAL traffic DOWN_NORMAL_RED_min2=62500 #min for doing the calculations (burst and etc) DOWN_NORMAL_RED_max=$((2 * $DOWN_NORMAL_RED_min2 + $DOWN_NORMAL_RED_min)) DOWN_NORMAL_RED_burst=$(((5 * $DOWN_NORMAL_RED_min2) / (3 * 1000))) DOWN_NORMAL_RED_limit=$(($DOWN_NORMAL_RED_max * 5)) #prio DOWN_RT_PRIO_RATE="500" #rate in kbit DOWN_RT_PRIO_UMAX="400" #length of the packets [byte]/ DOWN_RT_PRIO_DMAX="1.5" #delay in ms DOWN_UL_PRIO_RATE=$DOWNLOAD #Voip DOWN_UL_VOIP_RATE=$DOWNLOAD DOWN_SC_VOIP_RATE="250" DOWN_SC_VOIP_UMAX="350" #lengt of voip packets [byte] DOWN_SC_VOIP_DMAX="1.2" #delay in ms
/etc/shorewall/init The init file loads the ifb module, creating a single device: modprobe ifb numifbs=1 ip link set ifb0 up
/etc/shorewall/tcdevices The tcdevices file describes the two devices: #NUMBER: IN-BANDWITH OUT-BANDWIDTH OPTIONS REDIRECTED #INTERFACE INTERFACES 1:eth0 - ${UPLOAD}kbit hfsc,linklayer=ethernet,overhead=0 2:ifb0 - ${DOWNLOAD}kbit hfsc eth0
/etc/shorewall/tcclasses The tcclasses file defines the class hierarchy for both devices: #IFACE: MARK RATE: CEIL PRIORITY OPTIONS #CLASS DMAX:UMAX 1 1 ${UP_SC_VOIP_RATE}kbit:\ ${UP_SC_VOIP_DMAX}:\ ${UP_SC_VOIP_UMAX} ${UP_UL_VOIP_RATE}kbit 1 1 2 ${UP_RT_PRIO_RATE}kbit:\ ${UP_RT_PRIO_DMAX}:\ ${UP_RT_PRIO_UMAX} ${UP_LS_PRIO_RATE}kbit:\ ${UP_UL_PRIO_RATE}kbit 1 1 3 - ${UP_LS_NORMAL_RATE}kbit:\ ${UP_UL_NORMAL_RATE}kbit 1 red=(limit=$UP_NORMAL_RED_limit,\ min=$UP_NORMAL_RED_min,\ max=$UP_NORMAL_RED_max,\ burst=$UP_NORMAL_RED_burst,\ probability=$UP_NORMAL_RED_PROB,\ ecn) 1 4 - ${UP_LS_P2P_RATE}kbit:\ ${UP_UL_P2P_RATE}kbit 1 red=(limit=$UP_P2P_RED_limit,\ min=$UP_P2P_RED_min,\ max=$UP_P2P_RED_max,\ burst=$UP_P2P_RED_burst,\ probability=$UP_P2P_RED_PROB,\ ecn) 1 5 - ${UP_LS_BULK_RATE}kbit:\ ${UP_UL_BULK_RATE}kbit 1 default,\ red=(limit=$UP_BULK_RED_limit,\ min=$UP_BULK_RED_min,\ max=$UP_BULK_RED_max,\ burst=$UP_BULK_RED_burst,\ probability=$UP_BULK_RED_PROB,\ ecn) 2:10 - ${UP_SC_VOIP_RATE}kbit:\ ${UP_SC_VOIP_DMAX}:\ ${UP_SC_VOIP_UMAX} ${UP_UL_VOIP_RATE}kbit 1 2:20 - ${DOWN_RT_PRIO_RATE}kbit:\ ${DOWN_RT_PRIO_DMAX}:\ ${DOWN_RT_PRIO_UMAX} ${DOWN_UL_PRIO_RATE}kbit 1 2:30 - - ${DOWN_LS_NORMAL_RATE}kbit:\ ${DOWN_UL_NORMAL_RATE}kbit 1 red=(limit=$DOWN_NORMAL_RED_limit,\ min=$DOWN_NORMAL_RED_min,\ max=$DOWN_NORMAL_RED_max,\ burst=$DOWN_NORMAL_RED_burst,\ probability=$DOWN_NORMAL_RED_PROB) 2:40 - - ${DOWN_LS_P2P_RATE}kbit:\ ${DOWN_UL_P2P_RATE}kbit 1 red=(limit=$DOWN_P2P_RED_limit,\ min=$DOWN_P2P_RED_min,\ max=$DOWN_P2P_RED_max,\ burst=$DOWN_P2P_RED_burst,\ probability=$DOWN_P2P_RED_PROB) 2:50 - - ${DOWN_LS_BULK_RATE}kbit:\ ${DOWN_UL_BULK_RATE}kbit 1 default,\ red=(limit=$DOWN_BULK_RED_limit,\ min=$DOWN_BULK_RED_min,\ max=$DOWN_BULK_RED_max,\ burst=$DOWN_BULK_RED_burst,\ probability=$DOWN_BULK_RED_PROB)
/etc/shorewall/tcrules The tcrules file classifies upload packets: #MARK SOURCE DEST PROTO DEST SOURCE USER TEST # PORT(S) PORT(S) RESTORE:T - - - - - - !0:C CONTINUE:T - - - - - - !0 2:T - - icmp 1:T - - udp $UDP_VOIP - - 0 1:T $IP_VOIP - - - - - 0 1:T - $IP_VOIP - - - - 0 2:T - - tcp $TCP_PRIO - - 0 2:T - - udp $UDP_PRIO - - 0 2:T - - tcp - $TCP_PRIO - 0 2:T - - udp - $UDP_PRIO - 0 3:T - - tcp $TCP_NORMAL - - 0 4:T - - ipp2p:all - - - 0 5:T - - tcp $TCP_BULK - - 0 5:T - - tcp - $TCP_BULK - 0 5:T - - udp $UDP_BULK - - 0 5:T - - udp - $UDP_BULK - 0 SAVE:T - - - - - - !0
/etc/shorewall/tcfilters The tcfilters file classifies download packets: #INTERFACE: SOURCE DEST PROTO DEST SOURCE TOS LENGTH #CLASS PORT(S) PORT(S) # # These classify download traffic # 2:10 - $MYNET udp - $UDP_VOIP 2:20 - $MYNET tcp - $TCP_PRIO 2:20 - $MYNET udp - $UDP_PRIO 2:20 - $MYNET tcp $TCP_PRIO 2:20 - $MYNET udp $UDP_PRIO 2:30 - $MYNET tcp - $TCP_NORMAL 2:50 - $MYNET tcp $TCP_BULK 2:50 - $MYNET tcp - $TCP_BULK 2:50 - $MYNET udp $UDP_BULK 2:50 - $MYNET tcp - $UDP_BULK
shorewall-docs-xml-4.5.21/Shorewall_and_Routing.xml0000644000175000017500000002042012222401136022225 0ustar teastepteastep
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/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/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 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE 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-4.5.21/UPnP.xml0000644000175000017500000001153412222401136016564 0ustar teastepteastep
Shorewall and UPnP Tom Eastep 2005 2010 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.
UPnP Shorewall includes support for UPnP (Universal Plug and Play) using linux-igd (http://linux-igd.sourceforge.net). UPnP is required by a number of popular applications including MSN IM. From a security architecture viewpoint, UPnP is a disaster. It assumes that: All local systems and their users are completely trustworthy. No local system is infected with any worm or trojan. If either of these assumptions are not true then UPnP can be used to totally defeat your firewall and to allow incoming connections to arbitrary local systems on any port whatsoever. In short: USE UPnP AT YOUR OWN RISK. Shorewall and linux-igd implement a UPnP Internet Gateway Device. It will not allow clients on one LAN subnet to access a UPnP Media Server on another subnet.
linux-igd Configuration In /etc/upnpd.conf, you will want: create_forward_rules = yes prerouting_chain_name = UPnP forward_chain_name = forwardUPnP
Shorewall Configuration In /etc/shorewall/interfaces, you need the 'upnp' option on your external interface. Example: #ZONE INTERFACE BROADCAST OPTIONS net eth1 detect dhcp,routefilter,tcpflags,upnp If your loc->fw policy is not ACCEPT then you need this rule: #ACTION SOURCE DEST allowinUPnP loc $FW You MUST have this rule: #ACTION SOURCE DEST forwardUPnP net loc You must also ensure that you have a route to 224.0.0.0/4 on your internal (local) interface as described in the linux-igd documentation. The init script included with the Debian linux-idg package adds this route during start and deletes it during stop. Shorewall versions prior to 4.4.10 do not retain the dynamic rules added by linux-idg over a shorewall restart.
Shorewall on a UPnP Client It is sometimes desirable to run UPnP-enabled client programs like Transmission (BitTorrent client) on a Shorewall-protected system. Shorewall provides support for UPnP client access in the form of the upnpclient option in shorewall-interfaces (5). The upnpclient option causes Shorewall to detect the default gateway through the interface and to accept UDP packets from that gateway. Note that, like all aspects of UPnP, this is a security hole so use this option at your own risk. Note that when multiple clients behind the firewall use UPnP, they must configure their applications to use unique ports.
shorewall-docs-xml-4.5.21/MyNetwork.xml0000644000175000017500000010402712222401136017701 0ustar teastepteastep
My Network Configuration 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. The ruleset shown in this article uses Shorewall features that are not available in Shorewall versions prior to 4.4.0.
Introduction The configuration described in this article represents the network at shorewall.net during the summer of 2009. It uses the following Shorewall features: Two Internet Interfaces A DMZ with two "systems" using Proxy ARP and running in OpenVZ Virtual Environments IPv6 Access through a 6to4 Tunnel OpenVPN and IPSEC for access when we are on the road. Ipsets Dynamic Zones Transparent proxy using Squid Manual Chains Traffic Shaping Linux runs the firewall and the servers (although they run in OpenVZ containers on the firewall system). Linux is not used natively on any of our other systems except for an HP mini which runs HP Mobile Internet Experience (MIE) -- essentially Ubuntu Hardy. I rather run Windows natively (either Vista Home Premium or XP Professional) and run Linux in VMs under VirtualBox. This approach has a number of advantages: Efficient disk utilization. The virtual disks used by Linux are just files in the NTFS file system. There is no need to pre-allocate one or more partitions for use by Linux. Some large applications, like Google Earth, are installed only on Windows. Avoids proprietary hardware issues. The Linux VMs emulate standard hardware that is well-supported by Linux. Avoids DRM hassles All DRM-protected media can be handled under Windows. Websites that don't work with Firefox (or at least with Linux Firefox) VirtualBox is fast (when your processor supports virtualization extensions) and very easy to use. I highly recommend it!
Network Topology Our network is diagrammed in the following graphic. We have accounts with two different ISPs: Comcast This is a high-speed (20mb/4mb) link with a single dynamic IPv4 address. We are not allowed to run servers accessible through this account. Avvanta This is a low-speec (1.5mb/384kbit) link with five static IP address. Our servers are accessed through this account. The wired local network is restricted to my home office. The wireless network is managed by a Linksys WRT300N pre-N router which we use only as an access point -- its WAN interface is unused and it is configured to not do NAT. The wireless network uses WPA2 personal security and MAC filtering is enabled in the router. These two factors make it a hassle when guests visit with a laptop but provide good security for the network.
Shorewall Configuration This section contains exerpts from the Shorewall configuration. It is important to keep in mind that parts of my configuration are there just to provide a test bed for Shorewall features. So while they show correct usage, they don't necessarily provide any useful benefit. I have tried to point those out in the sub-sections that follow.
/etc/shorewall/params MIRRORS=62.216.169.37,\ 63.229.2.114,\ ... NTPSERVERS=... POPSERVERS=... LOG=ULOG INT_IF=eth1 EXT_IF=eth2 COM_IF=eth0 VPS_IF=venet0As shown, this file defines variables to hold the various lists of IP addresses that I need to maintain. To simplify network reconfiguration, I also use variables to define the log level and the network interfaces.
/etc/shorewall/shorewall.conf ############################################################################### # S T A R T U P E N A B L E D ############################################################################### STARTUP_ENABLED=Yes ############################################################################### # V E R B O S I T Y ############################################################################### VERBOSITY=0 ############################################################################### # C O M P I L E R # (setting this to 'perl' requires installation of Shorewall-perl) ############################################################################### SHOREWALL_COMPILER=perl ############################################################################### # L O G G I N G ############################################################################### LOGFILE=/var/log/ulog/syslogemu.log STARTUP_LOG=/var/log/shorewall-init.log LOG_VERBOSITY=2 LOGFORMAT="%s:%s:" LOGTAGONLY=No LOGRATE= LOGBURST= LOGALLNEW= BLACKLIST_LOGLEVEL= MACLIST_LOG_LEVEL= TCP_FLAGS_LOG_LEVEL=$LOG SMURF_LOG_LEVEL=$LOG LOG_MARTIANS=No ############################################################################### # L O C A T I O N O F F I L E S A N D D I R E C T O R I E S ############################################################################### IPTABLES= IPSET= PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin SHOREWALL_SHELL=/bin/sh SUBSYSLOCK= MODULESDIR= CONFIG_PATH=/etc/shorewall:/usr/share/shorewall RESTOREFILE= IPSECFILE=zones LOCKFILE= ############################################################################### # D E F A U L T A C T I O N S / M A C R O S ############################################################################### DROP_DEFAULT="Drop" REJECT_DEFAULT="Reject" ACCEPT_DEFAULT="none" QUEUE_DEFAULT="none" ############################################################################### # R S H / R C P C O M M A N D S ############################################################################### RSH_COMMAND='ssh ${root}@${system} ${command}' RCP_COMMAND='scp ${files} ${root}@${system}:${destination}' ############################################################################### # F I R E W A L L O P T I O N S ############################################################################### IP_FORWARDING=Yes ADD_IP_ALIASES=No ADD_SNAT_ALIASES=No RETAIN_ALIASES=No TC_ENABLED=Internal TC_EXPERT=No CLEAR_TC=Yes MARK_IN_FORWARD_CHAIN=Yes CLAMPMSS=Yes ROUTE_FILTER=No DETECT_DNAT_IPADDRS=Yes MUTEX_TIMEOUT=60 ADMINISABSENTMINDED=Yes BLACKLISTNEWONLY=Yes DELAYBLACKLISTLOAD=No MODULE_SUFFIX=ko DONT_LOAD= DISABLE_IPV6=No BRIDGING=No DYNAMIC_ZONES=No PKTTYPE=No MACLIST_TABLE=mangle MACLIST_TTL=60 SAVE_IPSETS=No MAPOLDACTIONS=No FASTACCEPT=No IMPLICIT_CONTINUE=Yes HIGH_ROUTE_MARKS=Yes USE_ACTIONS=Yes OPTIMIZE=1 EXPORTPARAMS=Yes EXPAND_POLICIES=Yes KEEP_RT_TABLES=No DELETE_THEN_ADD=No MULTICAST=Yes AUTO_COMMENT=Yes MANGLE_ENABLED=Yes NULL_ROUTE_RFC1918=Yes USE_DEFAULT_RT=No RESTORE_DEFAULT_ROUTE=No FAST_STOP=Yes AUTOMAKE=No LOG_MARTIANS=Yes WIDE_TC_MARKS=Yes ############################################################################### # P A C K E T D I S P O S I T I O N ############################################################################### BLACKLIST_DISPOSITION=DROP MACLIST_DISPOSITION=ACCEPT TCP_FLAGS_DISPOSITION=DROP I don't believe that there is anything remarkable there
/etc/shorewall/actions #ACTION Mirrors # Accept traffic from Shorewall Mirrors I make this into an action so the rather long list of rules go into their own chain.
/etc/shorewall/action.Mirrors #TARGET SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE # PORT PORT(S) DEST LIMIT COMMENT Accept traffic from Mirrors ACCEPT $MIRRORS See the rules file -- this action is used for rsync traffic.
/etc/shorewall/zones fw firewall loc ipv4 #Local Zone dmz ipv4 #DMZ net ipv4 #Internet vpn:loc,net ipsec #IPSEC drct:loc ipv4 #Direct internet accessThe vpn zone is mostly for testing Shorewall IPSEC support. It is nested in loc and net to test a feature added in Shorewall 4.4.0. The drct zone is a dynamic zone whose members bypass the transparent proxy. Some applications (such as VirtualBox registration) don't work through the proxy.
/etc/shorewall/interfaces #ZONE INTERFACE BROADCAST OPTIONS loc $INT_IF detect dhcp,logmartians=1,routefilter=1,tcpflags dmz $VPS_IF detect logmartians=1,routefilter=0,routeback net $EXT_IF detect dhcp,blacklist,tcpflags,optional,routefilter=0,nosmurfs,logmartians=0,proxyarp=1 net $COM_IF detect dhcp,blacklist,tcpflags,optional,upnp,routefilter=0,nosmurfs,logmartians=0 loc tun+ detectNotice that VPN clients are treated the same as local hosts. I set the proxyarp option on $EXT_IF so that The firewall will respond to ARP who-has requests for the servers in the DMZ. To keep OpenVZ happy (it issues dire warnings if the option is not set on the associated external interface).
/etc/shorewall/hosts #ZONE HOST(S) OPTIONS vpn $EXT_IF:0.0.0.0/0 vpn $COM_IF:0.0.0.0/0 vpn $INT_IF:0.0.0.0/0 drct $INT_IF:dynamicThe vpn zone includes ipsec hosts interfacing from either external interface as well as the local interface. drct is defined as dynamic through the local interface (recall that it is a sub-zone of loc).
/etc/shorewall/policy #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL $FW dmz REJECT $LOG $FW all ACCEPT loc net ACCEPT - loc fw ACCEPT loc vpn ACCEPT vpn fw ACCEPT vpn loc ACCEPT net net NONE net all DROP $LOG 8/sec:30 dmz fw REJECT $LOG all fw DROP $LOG all all REJECT $LOGI'm a bit sloppy with my fw<->loc policies -- I should fix that someday...
/etc/shorewall/accounting #ACTION CHAIN SOURCE DESTINATION PROTO DEST SOURCE USER/ # PORT(S) PORT(S) GROUP hp:COUNT accounting $COM_IF $INT_IF:172.20.1.107 UDP hp:COUNT accounting $INT_IF:172.20.1.107 $COM_IF UDP DONE hp mail:COUNT - $EXT_IF $VPS_IF:206.124.146.0/24 tcp 25 mail:COUNT - $VPS_IF:206.124.146.0/24 $EXT_IF tcp 25 DONE mail web - $EXT_IF $VPS_IF:206.124.146.0/24 tcp 80 web - $EXT_IF $VPS_IF:206.124.146.0/24 tcp 443 web - $VPS_IF:206.124.146.0/24 $EXT_IF tcp - 80 web - $VPS_IF:206.124.146.0/24 $EXT_IF tcp - 443 COUNT web $EXT_IF $VPS_IF:206.124.146.0/24 COUNT web $VPS_IF:206.124.146.0/24 $EXT_IF The accounting chains are as follows: hp Counts traffic to/from my work laptop to HP. The VPN users NAT-Traversal (UDP 4500) so I just count all UDP traffic to/from my work system. mail Incoming and outgoing email web Website traffic (both HTTP and HTTPS)
/etc/shorewall/blacklist #ADDRESS/SUBNET PROTOCOL PORT - udp 1024:1033,1434 - tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898This configuration silently drops a few ports that get lots of traffic.
/etc/shorewall/compile use strict; use Shorewall::Chains; my $chainref = ensure_manual_chain qw/DNS_DDoS/; add_rule $chainref, q(-m string --algo bm --from 30 --to 31 --hex-string "|010000010000000000000000020001|" -j DROP); add_rule $chainref, q(-m string --algo bm --from 30 --to 31 --hex-string "|000000010000000000000000020001|" -j DROP); add_rule $chainref, q(-j ACCEPT); 1;The above was created during a recent DDOS incident that targeted DNS servers. It illustrates how manual chains can be created.
/etc/shorewall/findgw if [ -f /var/lib/dhcp3/dhclient.${1}.leases ]; then grep 'option routers' /var/lib/dhcp3/dhclient.${1}.leases | tail -n 1 | while read j1 j2 gateway; do echo $gateway | sed 's/;//'; return 0; done fiThe Comcast line has a dynamic IP address assigned with the help of dhclient.
/etc/shorewall/isusable local status status=0 [ -f /etc/shorewall/${1}.status ] && status=$(cat /etc/shorewall/${1}.status) return $statusFor use with lsm.
/etc/shorewall/lib.private start_lsm() { killall lsm 2> /dev/null cat <<EOF > /etc/lsm/shorewall.conf connection { name=Avvanta checkip=206.124.146.254 device=$EXT_IF ttl=2 } connection { name=Comcast checkip=${ETH0_GATEWAY:-71.231.152.1} device=$COM_IF ttl=1 } EOF rm -f /etc/shorewall/*.status /usr/sbin/lsm /etc/lsm/lsm.conf >> /var/log/lsm } This function configures and starts lsm.
/etc/shorewall/masq #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 All connections out through Comcast must have the dynamically assigned address as their source address. Traffic from hosts without an Avvanta public IP address get 206.124.146.179 as their source address.
/etc/shorewall/notrack #SOURCE DESTINATION PROTO DEST SOURCE USER/ # PORT(S) PORT(S) GROUP net:!192.88.99.1 - 41 dmz 206.124.146.255 udp dmz 255.255.255.255 udp loc 172.20.1.255 udp loc 255.255.255.255 udp $FW 255.255.255.255 udp $FW 172.20.1.255 udp $FW 206.124.146.255 udpThis file omits the 6to4 traffic originating from 6to4 relays as well as broadcast traffic (which Netfilter doesn't handle).
/etc/shorewall/providers #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY Avvanta 1 0x10000 main $EXT_IF 206.124.146.254 track,loose,fallback $INT_IF,$VPS_IF,tun* Comcast 2 0x20000 main $COM_IF detect track,balance $INT_IF,$VPS_IF,tun*See the Multi-ISP article for an explaination of the multi-ISP aspects of this configuration.
/etc/shorewall/proxyarp <empty>As mentioned above, I set the proxyarp on the associated external interface instead of defining proxy ARP in this file.
/etc/shorewall/restored if [ -z "$(ps ax | grep 'lsm ' | grep -v 'grep ' )" ]; then start_lsm fi chmod 744 ${VARDIR}/stateIf lsm isn't running then start it. Make the state file world-readable.
/etc/shorewall/rtrules #SOURCE DEST PROVIDER PRIORITY - 172.20.0.0/24 main 1000 #OpenVPN clients - 206.124.146.177 main 1001 #Servers -- Routes configured by OpenVZ - 206.124.146.178 main 1001 # - 216.168.3.44 Avvanta 1001 #NNTP -- Does source IP verification 206.124.146.176/30 - Avvanta 26000 #Avvanta public IP addresses 206.124.146.180 - Avvanta 26000 #These entries simply ensure that outgoing traffic uses the correct interface.
/etc/shorewall/routestopped #INTERFACE HOST(S) OPTIONS PROTO $INT_IF 172.20.1.0/24 source,dest $VPS_IF 206.124.146.177,206.124.146.178 $EXT_IF - notrack 41Keep the lights on while Shorewall is stopped.
/etc/shorewall/rules ############################################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT PORT(S) DEST LIMIT GROUP ############################################################################################################################################################################### SECTION ESTABLISHED SECTION RELATED SECTION NEW REJECT:$LOG loc net tcp 25 #Stop direct loc->net SMTP (Comcast uses submission). REJECT:$LOG loc net udp 1025:1031 #MS Messaging COMMENT Stop NETBIOS crap 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 IP address DROP loc:!172.20.0.0/23 net COMMENT ############################################################################################################################################################################### # Local Network to Firewall # NONAT drct - REDIRECT- loc 3128 tcp 80 - !66.199.187.46,172.20.1.108,206.124.146.177,155.98.64.80,81.19.16.0/21 ############################################################################################################################################################################### # Local network to DMZ # ACCEPT loc dmz udp domain,177 ACCEPT loc dmz tcp ssh,smtp,465,587,www,ftp,imaps,domain,https,5901:5903 - ACCEPT loc dmz udp 33434:33524 ############################################################################################################################################################################### # Internet to ALL -- drop NewNotSyn packets # dropNotSyn net fw tcp dropNotSyn net loc tcp dropNotSyn net dmz tcp ############################################################################################################################################################################### # Internet to DMZ # DNS_DDoS net dmz udp domain ACCEPT net dmz tcp smtp,www,ftp,465,587,imaps,domain,https ACCEPT net dmz udp 33434:33454 Mirrors:none net dmz tcp 873 ACCEPT net dmz tcp 22 - - s:ssh:3/min:3 ############################################################################################################################################################# ################# # # Net to Local # Limit:$LOG:SSHA,3,60\ net loc tcp 22 # # BitTorrent from Wireless Network # #DNAT net:$COM_IF loc:172.20.1.102 tcp 6881:6889 #DNAT net:$COM_IF loc:172.20.1.102 udp 6881 # # UPnP # forwardUPnP net loc # # Silently Handle common probes # REJECT net loc tcp www,ftp,https DROP net loc icmp 8 ############################################################################################################################################################################### # DMZ to Internet # ACCEPT dmz net udp domain,ntp REJECT dmz net:$COM_IF tcp smtp ACCEPT dmz net tcp echo,ftp,ssh,smtp,whois,domain,www,81,nntp,https,2401,2702,2703,8080 ACCEPT dmz net:$POPSERVERS tcp pop3 # # Some FTP clients seem prone to sending the PORT command split over two packets. This prevents the FTP connection tracking # code from processing the command and setting up the proper expectation. The following rule allows active FTP to work in these cases # but logs the connection so I can keep an eye on this potential security hole. # ACCEPT:$LOG dmz net tcp 1024: 20 ############################################################################################################################################################################### # DMZ to Local # ACCEPT dmz loc tcp 22 - - s:ssh:3/min:3 ############################################################################################################################################################################### # DMZ to Firewall -- ntp & snmp Silently reject Auth # ACCEPT dmz fw tcp 161,ssh ACCEPT dmz fw udp 161,ntp REJECT dmz fw tcp auth ############################################################################################################################################################################### # Internet to Firewall # REJECT net fw tcp www,ftp,https DROP net fw icmp 8 ACCEPT net fw udp 33434:33454 ACCEPT net fw tcp 22 - - s:ssh:3/min:3 ACCEPT net fw udp 33434:33524 ############################################################################################################################################################################### # Firewall to DMZ # ACCEPT fw dmz tcp domain,www,ftp,ssh,smtp,https,993,465,587,5901 ACCEPT fw dmz udp domain REJECT fw dmz udp 137:139 ############################################################################################################################################################################## # COMMENT Freenode Probes DROP net:82.96.96.3,85.190.0.3 any COMMENT ############################################################################################################################################################################## # Allow Ping except where disallowed earlier # ACCEPT any any icmp 8
/etc/shorewall/started if [ -z "$(ps ax | grep 'lsm ' | grep -v 'grep ' )" ]; then start_lsm fi chmod 744 ${VARDIR}/stateIf lsm isn't running then start it. Make the state file world-readable.
/etc/shorewall/stopped if [ "$COMMAND" = stop -o "$COMMAND" = clear ]; then killall lsm 2> /dev/null fi chmod 744 ${VARDIR}/stateKill lsm if the command is stop or clear. Make the state file world-readable.
/etc/shorewall/tcdevices #INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS $EXT_IF - 300kbit classify $INT_IF - 80mbit classify $COM_IF - 4mbit classify,hfsc The use of HFSC on the Comcast link is largely to provide a test bed for that qdisc; I really don't have any real-time requirement such as VOIP.
/etc/shorewall/tcclasses #INTERFACE MARK RATE CEIL PRIORITY OPTIONS 1:110 - full/4 full 1 tcp-ack,tos-minimize-delay 1:120 - full/4 full 2 flow=nfct-src 1:130 - full/4 230kbit 3 default,flow=nfct-src 1:140 - full/4 230kbit 4 flow=nfct-src 2:10 - 95*full/100 full 1 flow=dst 2:100 - 14mbit 20mbit 2 2:100:101 - 7mbit 20mbit 3 default,flow=dst 2:100:102 - 7mbit 20mbit 3 flow=dst 3:10 - 2mbit:4ms full 1 flow=nfct-src 3:100 - 2mbit full 2 3:100:101 - 1mbit full 3 default,flow=nfct-src 3:100:102 - 1mbit full 3 flow=nfct-src Note that most of the outgoing bandwidth on the local interface is allocated to one class. That class is used for local traffic.
/etc/shorewall/tcfilters #INTERFACE: SOURCE DEST PROTO DEST SOURCE TOS LENGTH #CLASS PORT(S) PORT(S) # =============================== AVVANTA ==================================== # # Give Highest priority to LSM's pings to the gateway and to DNS queries # 1:110 206.124.146.176 206.124.146.254 icmp 1:110 206.124.146.177 - udp 53 # # Second Highest priority to IPv6 Tunnel # 1:120 206.124.146.180 # # Lowest priority to bulk traffic # 1:140 206.124.146.177 - tcp - 873 - 2048 1:140 206.124.146.177 - - - - tos-minimize-cost The tcfilters file is only used for the Avvanta provider because it has static public IP addresses.
/etc/shorewall/tcrules #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST LENGTH TOS # PORT(S) COMMENT Shape incoming traffic # # Most of the bandwidth is reserved for local traffic since the downlinks aren't that fast # 2:10 206.124.146.176/30 $INT_IF 2:10 206.124.146.177 $INT_IF 2:10 172.20.1.254 $INT_IF # # Guarantee 1/2 of the incoming bandwidth for my work system # 2:102 0.0.0.0/0 $INT_IF:172.20.1.107 COMMENT Shape outgoing traffic to Comcast # # Give 1/2 to my work system and add a latency guarantee # 3:10 172.20.1.107 $COM_IF # # Restrict Torrent uploads # 3:102 172.20.1.0/24 $COM_IF tcp - 6881:6889 The tcrules file is used to classify traffic that deals with the local network and/or with Comcast.
/etc/shorewall/tunnels #TYPE ZONE GATEWAY GATEWAY # ZONE openvpnserver:udp net 6to4 net ipsec net ipsec loc ipip vpn 0.0.0.0/0The ipip tunnel from the vpn zone handles IP compression on IPSEC connections.
shorewall-docs-xml-4.5.21/manpages/0000755000175000017500000000000012223303501017005 5ustar teastepteastepshorewall-docs-xml-4.5.21/manpages/shorewall-stoppedrules.xml0000644000175000017500000001533412222401136024266 0ustar teastepteastep shorewall-stoppedrules 5 stoppedrules The Shorewall file that governs what traffic flows through the firewall while it is in the 'stopped' state. /etc/shorewall/stoppedrules Description This file is used to define the hosts that are accessible when the firewall is stopped or is being stopped. Changes to this file do not take effect until after the next shorewall start, shorewall restart, or command. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ACTION - Determines the disposition of the packet. means that the packet will be accepted. indicates that no conntrack entry should be created for the packet. does not imply . SOURCE - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,address]...] matches packets originating on the firewall itself, while interface specifies packets arriving on the named interface. This column may also include a comma-separated list of IP/subnet addresses. If your kernel and iptables include iprange match support, IP address ranges are also allowed. Ipsets and exclusion are also supported. When or interface are specified, the list must be preceded by a colon (":"). If left empty or supplied as "-", 0.0.0.0/0 is assumed. DEST - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,address]...] matches packets addressed the firewall itself, while interface specifies packets arriving on the named interface. Neither may be specified if the target is . This column may also include a comma-separated list of IP/subnet addresses. If your kernel and iptables include iprange match support, IP address ranges are also allowed. Ipsets and exclusion are also supported. When or interface are specified, the list must be preceded by a colon (":"). If left empty or supplied as "-", 0.0.0.0/0 is assumed. PROTO (Optional) ‒ protocol-name-or-number[,...] Protocol. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. DEST PORT(S) (dport) ‒ service-name/port-number-list Optional. A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. SOURCE PORT(S) (sport) ‒ service-name/port-number-list Optional. A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel. FILES /etc/shorewall/stoppedrules See ALSO http://shorewall.net/starting_and_stopping_shorewall.htm http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-init.xml0000644000175000017500000001341412222401136022475 0ustar teastepteastep shorewall-init 8 shorewall-init Companion package /etc/init.d/shorewall-init start|stop Description Shorewall-init is an optional package (added in Shorewall 4.4.10) that can be installed along with Shorewall, Shorewall6, Shorewall-lite and/or Shorewall6-lite. It provides two key features: It can close (stop) the firewall during boot prior to starting the network. This can prevent unwanted connections from being accepted after the network comes up but before the firewall is started. It can interface with your distribution's ifup/ifdown scripts and/or NetworkManager to allow firewall actions when an interface starts or stops. These two capabilities can be enabled separately. After you install the shorewall-init package, you can activate it by modifying the Shorewall-init configuration file: On Debian-based system, the file is /etc/default/shorewall-init. On other systems, the file is /etc/sysconfig/shorewall-init. To activate the safe boot feature, edit the configuration file and set PRODUCTS to a space-separated list of Shorewall products that you want to be closed before networking starts. Example: PRODUCTS="shorewall shorewall6" You also must insure that the compiled scripts for the listed products are compiled using Shorewall 4.4.10 or later. Shorewall shorewall compile Shorewall6 shorewall6 compile Shorewall-lite On the administrative system, enter the command shorewall export firewall from the firewall's configuration directory. Shorewall6-lite On the administrative system, enter the command shorewall6 export firewall from the firewall's configuration directory. The second feature (ifup/ifdown and NetworkManager integration) should only be activated on systems that do not use a link status monitor line swping or LSM. Edit the configuration file and set IFUPDOWN=1 For NetworkManager integration, you will want to disable firewall startup at boot and delay it to when your interface comes up. For this to work correctly, you must set the required or the optional option on at least one interface then: On Debian-based systems, edit /etc/default/product for each product listed in the PRODUCTS setting and set startup=0. On other systems, use the distribution's service control tool (insserv, chkconfig, etc.) to disable startup of the products listed in the PRODUCTS setting. On a laptop with both Ethernet and wireless interfaces, you will want to make both interfaces optional and set the REQUIRE_INTERFACE option to Yes in shorewall.conf (5) or shorewall6.conf (5). This causes the firewall to remain stopped until at least one of the interfaces comes up. FILES /etc/default/shorewall-init (Debian-based systems) or /etc/sysconfig/shorewall-init (other distributions) See ALSO shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-lite.xml0000644000175000017500000011462212222401136022472 0ustar teastepteastep shorewall-lite 8 shorewall-lite Administration tool for Shoreline Firewall Lite (Shorewall Lite) shorewall-lite | -options interface[:host-list] zone shorewall-lite | -options address shorewall-lite | -options shorewall-lite | -options interface[:host-list] zone shorewall-lite | -options { interface | provider } shorewall-lite | -options address shorewall-lite | -options shorewall-lite | -options { interface | provider } shorewall-lite | -options filename shorewall-lite | -options shorewall-lite | -options shorewall-lite | -options address mask address/vlsm shorewall-lite | -options address1address2 shorewall-lite | -options iptables match expression shorewall-lite | -options address shorewall-lite | -options refresh-interval shorewall-lite | -options address shorewall-lite | -options iptables match expression shorewall-lite | -options address shorewall-lite | -options shorewall-lite | -options directory shorewall-lite | -options filename shorewall-lite | -options filename shorewall-lite | -options {|||} chain shorewall-lite | -options shorewall-lite | -options shorewall-lite | -options event shorewall-lite | -options shorewall-lite | -options shorewall-lite | -options shorewall-lite | -options shorewall-lite | -options shorewall-lite | -options shorewall-lite | -options Description The shorewall-lite utility is used to control the Shoreline Firewall Lite (Shorewall Lite). Options The and options are used for debugging. See http://www.shorewall.net/starting_and_stopping_shorewall.htm#Trace. The nolock prevents the command from attempting to acquire the Shorewall-lite lockfile. It is useful if you need to include shorewall commands in /etc/shorewall/started. The options control the amount of output that the command produces. They consist of a sequence of the letters v and q. If the options are omitted, the amount of output is determined by the setting of the VERBOSITY parameter in shorewall.conf(5). Each v adds one to the effective verbosity and each q subtracts one from the effective VERBOSITY. Alternately, v may be followed immediately with one of -1,0,1,2 to specify a specify VERBOSITY. There may be no white-space between v and the VERBOSITY. The options may also include the letter which causes all progress messages to be timestamped. Commands The available commands are listed below. add Adds a list of hosts or subnets to a dynamic zone usually used with VPN's. The interface argument names an interface defined in the shorewall-interfaces(5) file. A host-list is comma-separated list whose elements are host or network addresses. The add command is not very robust. If there are errors in the host-list, you may see a large number of error messages yet a subsequent shorewall-lite show zones command will indicate that all hosts were added. If this happens, replace add by delete and run the same command again. Then enter the correct command. allow Re-enables receipt of packets from hosts previously blacklisted by a drop, logdrop, reject, or logreject command. clear Clear will remove all rules and chains installed by Shorewall-lite. The firewall is then wide open and unprotected. Existing connections are untouched. Clear is often used to see if the firewall is causing connection problems. If is given, the command will be processed by the compiled script that executed the last successful start, restart or refresh command if that script exists. delete The delete command reverses the effect of an earlier add command. The interface argument names an interface defined in the shorewall-interfaces(5) file. A host-list is comma-separated list whose elements are a host or network address. disable Added in Shorewall 4.4.26. Disables the optional provider associated with the specified interface or provider. Where more than one provider share a single network interface, a provider name must be given. drop Causes traffic from the listed addresses to be silently dropped. dump Produces a verbose report about the firewall configuration for the purpose of problem analysis. The -x option causes actual packet and byte counts to be displayed. Without that option, these counts are abbreviated. The -m option causes any MAC addresses included in Shorewall-lite log messages to be displayed. The -l option causes the rule number for each Netfilter rule to be displayed. enable Added in Shorewall 4.4.26. Enables the optional provider associated with the specified interface or provider. Where more than one provider share a single network interface, a provider name must be given. forget Deletes /var/lib/shorewall-lite/filename and /var/lib/shorewall-lite/save. If no filename is given then the file specified by RESTOREFILE in shorewall.conf(5) is assumed. help Displays a syntax summary. hits Generates several reports from Shorewall-lite log messages in the current log file. If the option is included, the reports are restricted to log messages generated today. ipcalc Ipcalc displays the network address, broadcast address, network in CIDR notation and netmask corresponding to the input[s]. iprange Iprange decomposes the specified range of IP addresses into the equivalent list of network/host addresses. iptrace This is a low-level debugging command that causes iptables TRACE log records to be created. See iptables(8) for details. The iptables match expression must be one or more matches that may appear in both the raw table OUTPUT and raw table PREROUTING chains. The trace records are written to the kernel's log buffer with facility = kernel and priority = warning, and they are routed from there by your logging daemon (syslogd, rsyslog, syslog-ng, ...) -- Shorewall-lite has no control over where the messages go; consult your logging daemon's documentation. logdrop Causes traffic from the listed addresses to be logged then discarded. Logging occurs at the log level specified by the BLACKLIST_LOGLEVEL setting in shorewall.conf (5). logwatch Monitors the log file specified by the LOGFILE option in shorewall.conf(5) and produces an audible alarm when new Shorewall-lite messages are logged. The -m option causes the MAC address of each packet source to be displayed if that information is available. The refresh-interval specifies the time in seconds between screen refreshes. You can enter a negative number by preceding the number with "--" (e.g., shorewall-lite logwatch -- -30). In this case, when a packet count changes, you will be prompted to hit any key to resume screen refreshes. logreject Causes traffic from the listed addresses to be logged then rejected. Logging occurs at the log level specified by the BLACKLIST_LOGLEVEL setting in shorewall.conf (5). noiptrace This is a low-level debugging command that cancels a trace started by a preceding iptrace command. The iptables match expression must be one given in the iptrace command being canceled. reset All the packet and byte counters in the firewall are reset. restart Restart is similar to shorewall-lite start except that it assumes that the firewall is already started. Existing connections are maintained. The option causes Shorewall-lite to avoid updating the routing table(s). The option causes the connection tracking table to be flushed; the conntrack utility must be installed to use this option. restore Restore Shorewall-lite to a state saved using the shorewall-lite save command. Existing connections are maintained. The filename names a restore file in /var/lib/shorewall-lite created using shorewall-lite save; if no filename is given then Shorewall-lite will be restored from the file specified by the RESTOREFILE option in shorewall.conf(5). save The dynamic blacklist is stored in /var/lib/shorewall-lite/save. The state of the firewall is stored in /var/lib/shorewall-lite/filename for use by the shorewall-lite restore. If filename is not given then the state is saved in the file specified by the RESTOREFILE option in shorewall.conf(5). show The show command can have a number of different arguments: capabilities Displays your kernel/iptables capabilities. The -f option causes the display to be formatted as a capabilities file for use with compile -e. [ [ ] chain... ] The rules in each chain are displayed using the iptables -L chain -n -v command. If no chain is given, all of the chains in the filter table are displayed. The -x option is passed directly through to iptables and causes actual packet and byte counts to be displayed. Without this option, those counts are abbreviated. The -t option specifies the Netfilter table to display. The default is filter. The -b ('brief') option causes rules which have not been used (i.e. which have zero packet and byte counts) to be omitted from the output. Chains with no rules displayed are also omitted from the output. The -l option causes the rule number for each Netfilter rule to be displayed. If the t option and the keyword are both omitted and any of the listed chains do not exist, a usage message is displayed. classifiers|filters Displays information about the packet classifiers defined on the system as a result of traffic shaping configuration. config Displays distribution-specific defaults. connections Displays the IP connections currently being tracked by the firewall. event event Added in Shorewall 4.5.19. Displays the named event. events Added in Shorewall 4.5.19. Displays all events. ip Displays the system's IPv4 configuration. ipa Added in Shorewall 4.4.17. Displays the per-IP accounting counters (shorewall-accounting (5)). log Displays the last 20 Shorewall-lite messages from the log file specified by the LOGFILE option in shorewall.conf(5). The -m option causes the MAC address of each packet source to be displayed if that information is available. marks Added in Shorewall 4.4.26. Displays the various fields in packet marks giving the min and max value (in both decimal and hex) and the applicable mask (in hex). nat Displays the Netfilter nat table using the command iptables -t nat -L -n -v.The -x option is passed directly through to iptables and causes actual packet and byte counts to be displayed. Without this option, those counts are abbreviated. policies Added in Shorewall 4.4.4. Displays the applicable policy between each pair of zones. Note that implicit intrazone ACCEPT policies are not displayed for zones associated with a single network where that network doesn't specify . routing Displays the system's IPv4 routing configuration. raw Displays the Netfilter raw table using the command iptables -t raw -L -n -v.The -x option is passed directly through to iptables and causes actual packet and byte counts to be displayed. Without this option, those counts are abbreviated. tc Displays information about queuing disciplines, classes and filters. zones Displays the current composition of the Shorewall zones on the system. start Start Shorewall Lite. Existing connections through shorewall-lite managed interfaces are untouched. New connections will be allowed only if they are allowed by the firewall rules or policies. The option causes the connection tracking table to be flushed; the conntrack utility must be installed to use this option. stop Stops the firewall. All existing connections, except those listed in shorewall-routestopped(5) or permitted by the ADMINISABSENTMINDED option in shorewall.conf(5), are taken down. The only new traffic permitted through the firewall is from systems listed in shorewall-routestopped(5) or by ADMINISABSENTMINDED. If is given, the command will be processed by the compiled script that executed the last successful start, restart or refresh command if that script exists. status Produces a short report about the state of the Shorewall-configured firewall. version Displays Shorewall's version. The option is included for compatibility with earlier Shorewall releases and is ignored. EXIT STATUS In general, when a command succeeds, status 0 is returned; when the command fails, a non-zero status is returned. The status command returns exit status as follows: 0 - Firewall is started. 3 - Firewall is stopped or cleared 4 - Unknown state; usually means that the firewall has never been started. FILES /etc/shorewall-lite/ See ALSO http://www.shorewall.net/starting_and_stopping_shorewall.htm shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-actions.xml0000644000175000017500000001205212222401136023167 0ustar teastepteastep shorewall-actions 5 actions Shorewall action declaration file /etc/shorewall/actions Description This file allows you to define new ACTIONS for use in rules (see shorewall-rules(5)). You define the iptables rules to be performed in an ACTION in /etc/shorewall/action.action-name. Columns are: NAME The name of the action. ACTION names should begin with an upper-case letter to distinguish them from Shorewall-generated chain names and be composed of letters, digits or numbers. If you intend to log from the action then the name must be no longer than 11 characters in length if you use the standard LOGFORMAT. OPTIONS Added in Shorewall 4.5.10. Available options are: builtin Added in Shorewall 4.5.16. Defines the action as a rule target that is supported by your iptables but is not directly supported by Shorewall. The action may be used as the rule target in an INLINE rule in shorewall-rules(5). inline Causes the action body (defined in action.action-name) to be expanded in-line like a macro rather than in its own chain. You can list Shorewall Standard Actions in this file to specify the option. Some of the Shorewall standard actions cannot be used in-line and will generate a warning and the compiler will ignore if you try to use them that way: Broadcast DropSmurfs Invalid (Prior to Shorewall 4.5.13) NotSyn (Prior to Shorewall 4.5.13) RST (Prior to Shorewall 4.5.13) TCPFlags noinline Causes any later option for the same action to be ignored with a warning. nolog Added in Shorewall 4.5.11. When this option is specified, the compiler does not automatically apply the log level and/or tag from the invocation of the action to all rules inside of the action. Rather, it simply sets the $_loglevel and $_logtag shell variables which can be used within the action body to apply those logging options only to a subset of the rules. FILES /etc/shorewall/actions See ALSO http://shorewall.net/Actions.html shorewall(8), shorewall-accounting(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-params.xml0000644000175000017500000001006412222401136023013 0ustar teastepteastep shorewall-params 5 params Shorewall parameters file /etc/shorewall/params Description Assign any shell variables that you need in this file. The file is always processed by /bin/sh or by the shell specified through SHOREWALL_SHELL in shorewall.conf (5) so the full range of shell capabilities may be used. 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 VERBOSE VERBOSE_OFFSET VERSION Example params file: NET_IF=eth0 NET_BCAST=130.252.100.255 NET_OPTIONS=routefilter,norfc1918 Example shorewall-interfaces(5) file. ZONE INTERFACE BROADCAST OPTIONS net $NET_IF $NET_BCAST $NET_OPTIONS This is the same as if the interfaces file had contained: ZONE INTERFACE BROADCAST OPTIONS net eth0 130.252.100.255 routefilter,norfc1918 FILES /etc/shorewall/params See ALSO http://www.shorewall.net/configuration_file_basics.htm#Variables shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-ipsets.xml0000644000175000017500000001117312222401136023041 0ustar teastepteastep shorewall-ipsets 5 ipsets Specifying the name if an ipset in Shorewall configuration files +ipsetname +ipsetname[flag,...] +[ipsetname,...] Description Note: In the above syntax descriptions, the square brackets ("[]") are to be taken literally rather than as meta-characters. In most places where a network address may be entered, an ipset may be substituted. Set names must be prefixed by the character "+", must start with a letter and may be composed of alphanumeric characters, "-" and "_". Whether the set is matched against the packet source or destination is determined by which column the set name appears (SOURCE or DEST). For those set types that specify a tuple, two alternative syntaxes are available: [number] - Indicates that 'src' or 'dst' should be repeated number times. Example: myset[2]. [flag,...] where flag is or . Example: myset[src,dst]. In a SOURCE column, the following pairs are equivalent: +myset[2] and +myset[src,src] In a DEST column, the following pairs are equivalent: +myset[2] and +myset[dst,dst] Beginning with Shorewall 4.4.14, multiple source or destination matches may be specified by enclosing the set names within +[...]. The set names need not be prefixed with '+'. When such a list of sets is specified, matching packets must match all of the listed sets. For information about set lists and exclusion, see shorewall-exclusion (5). Beginning with Shorewall 4.5.16, you can increment one or more nfacct objects each time a packet matches an ipset. You do that by listing the objects separated by commas within parentheses. Example: +myset[src](myobject) In that example, when the source address of a packet matches the myset ipset, the myobject nfacct counter will be incremented. Examples +myset +myset[src] +myset[2] +[myset1,myset2[dst]] FILES /etc/shorewall/accounting /etc/shorewall/blacklist /etc/shorewall/hosts -- Note: Multiple matches enclosed in +[...] may not be used in this file. /etc/shorewall/maclist -- Note: Multiple matches enclosed in +[...] may not be used in this file. /etc/shorewall/masq /etc/shorewall/rules /etc/shorewall/secmarks /etc/shorewall/tcrules See ALSO shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-modules.xml0000644000175000017500000000626612222401136023211 0ustar teastepteastep shorewall-modules 5 modules Shorewall file /usr/share/shorewall/modules /usr/share/shorewall/helpers Description These files specify which kernel modules Shorewall will load before trying to determine your iptables/kernel's capabilities. The modules file is used when LOAD_HELPERS_ONLY=No in shorewall.conf(8); the helpers file is used when LOAD_HELPERS_ONLY=Yes Each record in the files has the following format: loadmodule modulename moduleoption The modulename names a kernel module (without suffix). Shorewall will search for modules based on your MODULESDIR and MODULE_SUFFIX settings in shorewall.conf(8). The moduleoptions are passed to modprobe (if installed) or to insmod. The /usr/share/shorewall/modules file contains a large number of modules. Users are encouraged to copy the file to /etc/shorewall/modules and modify the copy to load only the modules required or to use LOAD_HELPERS_ONLY=Yes. If you build monolithic kernels and have not installed module-init-tools, then create an empty /etc/shorewall/modules file; that will prevent Shorewall from trying to load modules at all. Example loadmodule ip_conntrack_ftp ports=21,221 FILES /usr/share/shorewall/modules /usr/share/shorewall/helpers /etc/shorewall/modules /etc/shorewall/helpers See ALSO shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-conntrack.xml0000644000175000017500000004655712222401136023532 0ustar teastepteastep shorewall6-conntrack 5 conntrack shorewall conntrack file /etc/shorewall/conntrack Description The original intent of the notrack file was to exempt certain traffic from Netfilter connection tracking. Traffic matching entries in the file were not to be tracked. The role of the file was expanded in Shorewall 4.4.27 to include all rules that can be added in the Netfilter raw table. In 4.5.7, the file's name was changed to conntrack. The file supports two different column layouts: FORMAT 1, FORMAT 2, and FORMAT 3, FORMAT 1 being the default. The three differ as follows: in FORMAT 2 and 3, there is an additional leading ACTION column. in FORMAT 3, the SOURCE column accepts no zone name; rather the ACTION column allows a SUFFIX that determines the chain(s) that the generated rule will be added to. When an entry in the following form is encountered, the format of the following entries are assumed to be of the specified format. [?]FORMAT format where format is either 1,2 or 3. Format 3 was introduced in Shorewall 4.5.10. The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is the preferred form; the form without the '?' is deprecated. Comments may be attached to Netfilter rules generated from entries in this file through the use of COMMENT lines. These lines begin with the word COMMENT; the remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word COMMENT. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ACTION - {NOTRACK|CT:helper:name[(arg=val[,...])|CT:notrack|DROP}[:chain-designator] This column is only present when FORMAT >= 2. Values other than NOTRACK or DROP require CT Target support in your iptables and kernel. or Disables connection tracking for this packet. Added in Shorewall 4.5.10. Silently discard the packet. :name Attach the helper identified by the name to this connection. This is more flexible than loading the conntrack helper with preset ports. At this writing, the available helpers are: amanda Requires that the amanda netfilter helper is present. ftp Requires that the FTP netfilter helper is present. irc Requires that the IRC netfilter helper is present. netbios-ns Requires that the netbios_ns (sic) helper is present. RAS and Q.931 These require that the H323 netfilter helper is present. pptp Requires that the pptp netfilter helper is present. sane Requires that the SANE netfilter helper is present. sip Requires that the SIP netfilter helper is present. snmp Requires that the SNMP netfilter helper is present. tftp Requires that the TFTP netfilter helper is present. May be followed by an option list of arg=val pairs in parentheses: =event[,...] Only generate the specified conntrack events for this connection. Possible event types are: new, related, destroy, reply, assured, protoinfo, helper, mark (this is connection mark, not packet mark), natseqinfo, and secmark. If more than one event is listed, the event list must be enclosed in parentheses (e.g., ctevents=(new,related)). Only generate a new expectation events for this connection. When FORMAT = 1, this column is not present and the rule is processed as if NOTRACK had been entered in this column. Beginning with Shorewall 4.5.10, when FORMAT = 3, this column can end with a colon followed by a chain-designator. The chain-designator can be one of the following: P The rule is added to the raw table PREROUTING chain. This is the default if no chain-designator is present. O The rule is added to the raw table OUTPUT chain. PO or OP The rule is added to the raw table PREROUTING and OUTPUT chains. SOURCE (formats 1 and 2) ‒ {zone[:interface][:address-list]|COMMENT} where zone is the name of a zone, interface is an interface to that zone, and address-list is a comma-separated list of addresses (may contain exclusion - see shorewall-exclusion (5)). Beginning with Shorewall 4.5.7, can be used as the zone name to mean all zones. Beginning with Shorewall 4.5.10, can be used as the zone name to mean all off-firewall zones. SOURCE (format 3) ‒ {-|interface[:address-list]|address-list} Where interface is an interface to that zone, and address-list is a comma-separated list of addresses (may contain exclusion - see shorewall-exclusion (5)). COMMENT is only allowed in format 1; the remainder of the line is treated as a comment that will be associated with the generated rule(s). DEST ‒ {-|interface[:address-list]|address-list} where address-list is a comma-separated list of addresses (may contain exclusion - see shorewall6-exclusion (5)). PROTO ‒ protocol-name-or-number[,...] A protocol name from /etc/protocols or a protocol number. Beginning with Shorewall 4.5.12, this column is labeled PROTOS and can accept a comma-separated list of protocols. Either proto or protos is accepted in the alternate input format. DEST PORT(S) (dport) - port-number/service-name-list A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. SOURCE PORT(S) (sport) - port-number/service-name-list A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel. USER/GROUP (user) ‒ [user][:group] May only be specified if the SOURCE zone is $FW. Specifies the effective user id and or group id of the process sending the traffic. SWITCH - [!]switch-name[={0|1}] Added in Shorewall 4.5.10 and allows enabling and disabling the rule without requiring shorewall restart. The rule is enabled if the value stored in /proc/net/nf_condition/switch-name is 1. The rule is disabled if that file contains 0 (the default). If '!' is supplied, the test is inverted such that the rule is enabled if the file contains 0. Within the switch-name, '@0' and '@{0}' are replaced by the name of the chain to which the rule is a added. The switch-name (after '...' expansion) must begin with a letter and be composed of letters, decimal digits, underscores or hyphens. Switch names must be 30 characters or less in length. Switches are normally off. To turn a switch on: echo 1 > /proc/net/nf_condition/switch-name To turn it off again: echo 0 > /proc/net/nf_condition/switch-name Switch settings are retained over shorewall restart. When the switch-name is followed by or , then the switch is initialized to off or on respectively by the start command. Other commands do not affect the switch setting. EXAMPLE Example 1: #ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP # PORT(S) PORT(S) CT:helper:ftp(expevents=new) fw - tcp 21 Example 2 (Shorewall 4.5.10 or later): Drop traffic to/from all zones to IP address 1.2.3.4 FORMAT 2 #ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP # PORT(S) PORT(S) DROP all-:1.2.3.4 - DROP all 1.2.3.4 orFORMAT 3 #ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP # PORT(S) PORT(S) DROP:P 1.2.3.4 - DROP:PO - 1.2.3.4 FILES /etc/shorewall/notrack See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall.xml0000644000175000017500000021323212222401136021534 0ustar teastepteastep shorewall 8 shorewall Administration tool for Shoreline Firewall (Shorewall) shorewall | -options interface[:host-list] zone zone host-list shorewall | -options address shorewall | -options directory shorewall | -options shorewall | -options directory pathname shorewall | -options interface[:host-list] zone zone host-list shorewall | -options { interface | provider } shorewall | -options address shorewall | -options shorewall | -options { interface | provider } shorewall | -options directory1 [user@]system[directory2] shorewall | -options filename shorewall | -options shorewall | -options shorewall | -options address mask address/vlsm shorewall | -options address1address2 shorewall | -options iptables match expression shorewall | -options root-user-name directory system shorewall | -options address shorewall | -options refresh-interval shorewall | -options address shorewall | -options iptables match expression shorewall | -options - directory chain shorewall | -options address shorewall | -options root-user-name directory system shorewall | -options shorewall | -options directory shorewall | -options filename shorewall | -options timeout directory shorewall | -options timeout directory shorewall | -options filename shorewall | -options {|||} chain shorewall | -options shorewall | -options shorewall | -options event shorewall | -options macro shorewall | -options shorewall | -options shorewall | -options shorewall | -options directory shorewall | -options shorewall | -options shorewall | -options directory timeout shorewall | -options directory shorewall | -options Description The shorewall utility is used to control the Shoreline Firewall (Shorewall). Options The and options are used for debugging. See http://www.shorewall.net/starting_and_stopping_shorewall.htm#Trace. The nolock prevents the command from attempting to acquire the Shorewall lockfile. It is useful if you need to include shorewall commands in /etc/shorewall/started. The options control the amount of output that the command produces. They consist of a sequence of the letters v and q. If the options are omitted, the amount of output is determined by the setting of the VERBOSITY parameter in shorewall.conf(5). Each v adds one to the effective verbosity and each q subtracts one from the effective VERBOSITY. Alternatively, v may be followed immediately with one of -1,0,1,2 to specify a specify VERBOSITY. There may be no white-space between v and the VERBOSITY. The options may also include the letter which causes all progress messages to be timestamped. Commands The available commands are listed below. add Adds a list of hosts or subnets to a dynamic zone usually used with VPN's. The interface argument names an interface defined in the shorewall-interfaces(5) file. A host-list is comma-separated list whose elements are host or network addresses. The add command is not very robust. If there are errors in the host-list, you may see a large number of error messages yet a subsequent shorewall show zones command will indicate that all hosts were added. If this happens, replace add by delete and run the same command again. Then enter the correct command. Beginning with Shorewall 4.5.9, the dynamic_shared zone option (shorewall-zones(5)) allows a single ipset to handle entries for multiple interfaces. When that option is specified for a zone, the add command has the alternative syntax in which the zone name precedes the host-list. allow Re-enables receipt of packets from hosts previously blacklisted by a drop, logdrop, reject, or logreject command. check Compiles the configuration in the specified directory and discards the compiled output script. If no directory is given, then /etc/shorewall is assumed. The -e option causes the compiler to look for a file named capabilities. This file is produced using the command shorewall-lite show -f capabilities > capabilities on a system with Shorewall Lite installed. The option causes the compiler to be run under control of the Perl debugger. The option causes the compiler to be profiled via the Perl command-line option. The option was added in Shorewall 4.5.2 and causes the compiler to print the generated ruleset to standard out. The option was added in Shorewall 4.4.20 and causes a Perl stack trace to be included with each compiler-generated error and warning message. clear Clear will remove all rules and chains installed by Shorewall. The firewall is then wide open and unprotected. Existing connections are untouched. Clear is often used to see if the firewall is causing connection problems. If is given, the command will be processed by the compiled script that executed the last successful start, restart or refresh command if that script exists. compile Compiles the current configuration into the executable file pathname. If a directory is supplied, Shorewall will look in that directory first for configuration files. If the pathname is omitted, the file firewall in the VARDIR (normally /var/lib/shorewall/) is assumed. A pathname of '-' causes the compiler to send the generated script to it's standard output file. Note that '-v-1' is usually specified in this case (e.g., shorewall -v-1 compile -- -) to suppress the 'Compiling...' message normally generated by /sbin/shorewall. When -e is specified, the compilation is being performed on a system other than where the compiled script will run. This option disables certain configuration options that require the script to be compiled where it is to be run. The use of -e requires the presence of a configuration file named capabilities which may be produced using the command shorewall-lite show -f capabilities > capabilities on a system with Shorewall Lite installed The -c option was added in Shorewall 4.5.17 and causes conditional compilation of a script. The script specified by pathname (or implied if pathname is omitted) is compiled if it doesn't exist or if there is any file in the directory or in a directory on the CONFIG_PATH that has a modification time later than the file to be compiled. When no compilation is needed, a message is issued and an exit status of zero is returned. The option causes the compiler to be run under control of the Perl debugger. The option causes the compiler to be profiled via the Perl command-line option. The option was added in Shorewall 4.4.20 and causes a Perl stack trace to be included with each compiler-generated error and warning message. delete The delete command reverses the effect of an earlier add command. The interface argument names an interface defined in the shorewall-interfaces(5) file. A host-list is comma-separated list whose elements are a host or network address. Beginning with Shorewall 4.5.9, the dynamic_shared zone option (shorewall-zones(5)) allows a single ipset to handle entries for multiple interfaces. When that option is specified for a zone, the delete command has the alternative syntax in which the zone name precedes the host-list. disable Added in Shorewall 4.4.26. Disables the optional provider associated with the specified interface or provider. Where more than one provider share a single network interface, a provider name must be given. Beginning with Shorewall 4.5.10, this command may be used with any optional network interface. interface may be either the logical or physical name of the interface. The command removes any routes added from shorewall-routes(5) and any traffic shaping configuration for the interface. drop Causes traffic from the listed addresses to be silently dropped. dump Produces a verbose report about the firewall configuration for the purpose of problem analysis. The -x option causes actual packet and byte counts to be displayed. Without that option, these counts are abbreviated. The -m option causes any MAC addresses included in Shorewall log messages to be displayed. The -l option causes the rule number for each Netfilter rule to be displayed. enable Added in Shorewall 4.4.26. Enables the optional provider associated with the specified interface or provider. Where more than one provider share a single network interface, a provider name must be given. Beginning with Shorewall 4.5.10, this command may be used with any optional network interface. interface may be either the logical or physical name of the interface. The command sets /proc entries for the interface, adds any route specified in shorewall-routes(5) and installs the interface's traffic shaping configuration, if any. export If directory1 is omitted, the current working directory is assumed. Allows a non-root user to compile a shorewall script and stage it on a system (provided that the user has access to the system via ssh). The command is equivalent to: /sbin/shorewall compile -e directory1 directory1/firewall &&\ scp directory1/firewall directory1/firewall.conf [user@]system:[directory2] In other words, the configuration in the specified (or defaulted) directory is compiled to a file called firewall in that directory. If compilation succeeds, then firewall and firewall.conf are copied to system using scp. forget Deletes /var/lib/shorewall/filename and /var/lib/shorewall/save. If no filename is given then the file specified by RESTOREFILE in shorewall.conf(5) is assumed. help Displays a syntax summary. hits Generates several reports from Shorewall log messages in the current log file. If the option is included, the reports are restricted to log messages generated today. ipcalc Ipcalc displays the network address, broadcast address, network in CIDR notation and netmask corresponding to the input[s]. iprange Iprange decomposes the specified range of IP addresses into the equivalent list of network/host addresses. iptrace This is a low-level debugging command that causes iptables TRACE log records to be created. See iptables(8) for details. The iptables match expression must be one or more matches that may appear in both the raw table OUTPUT and raw table PREROUTING chains. The trace records are written to the kernel's log buffer with facility = kernel and priority = warning, and they are routed from there by your logging daemon (syslogd, rsyslog, syslog-ng, ...) -- Shorewall has no control over where the messages go; consult your logging daemon's documentation. load If directory is omitted, the current working directory is assumed. Allows a non-root user to compile a shorewall script and install it on a system (provided that the user has root access to the system via ssh). The command is equivalent to: /sbin/shorewall compile -e directory directory/firewall &&\ scp directory/firewall directory/firewall.conf root@system:/var/lib/shorewall-lite/ &&\ ssh root@system '/sbin/shorewall-lite start' In other words, the configuration in the specified (or defaulted) directory is compiled to a file called firewall in that directory. If compilation succeeds, then firewall is copied to system using scp. If the copy succeeds, Shorewall Lite on system is started via ssh. If -s is specified and the start command succeeds, then the remote Shorewall-lite configuration is saved by executing shorewall-lite save via ssh. if -c is included, the command shorewall-lite show capabilities -f > /var/lib/shorewall-lite/capabilities is executed via ssh then the generated file is copied to directory using scp. This step is performed before the configuration is compiled. If is included, it specifies that the root user on system is named root-user-name rather than "root". The option was added in Shorewall 4.5.3 and causes a Perl stack trace to be included with each compiler-generated error and warning message. logdrop Causes traffic from the listed addresses to be logged then discarded. Logging occurs at the log level specified by the BLACKLIST_LOGLEVEL setting in shorewall.conf (5). logwatch Monitors the log file specified by the LOGFILE option in shorewall.conf(5) and produces an audible alarm when new Shorewall messages are logged. The -m option causes the MAC address of each packet source to be displayed if that information is available. The refresh-interval specifies the time in seconds between screen refreshes. You can enter a negative number by preceding the number with "--" (e.g., shorewall logwatch -- -30). In this case, when a packet count changes, you will be prompted to hit any key to resume screen refreshes. logreject Causes traffic from the listed addresses to be logged then rejected. Logging occurs at the log level specified by the BLACKLIST_LOGLEVEL setting in shorewall.conf (5). noiptrace This is a low-level debugging command that cancels a trace started by a preceding iptrace command. The iptables match expression must be one given in the iptrace command being canceled. refresh All steps performed by restart are performed by refresh with the exception that refresh only recreates the chains specified in the command while restart recreates the entire Netfilter ruleset. If no chain is given, the static blacklisting chain blacklst is assumed. The listed chains are assumed to be in the filter table. You can refresh chains in other tables by prefixing the chain name with the table name followed by ":" (e.g., nat:net_dnat). Chain names which follow are assumed to be in that table until the end of the list or until an entry in the list names another table. Built-in chains such as FORWARD may not be refreshed. The option was added in Shorewall 4.5.3 causes Shorewall to avoid updating the routing table(s). The option was added in Shorewall 4.5.3 causes the compiler to run under the Perl debugger. The option was added in Shorewall 4.5.3 and causes a Perl stack trace to be included with each compiler-generated error and warning message. The - option was added in Shorewall 4.5.3 and causes Shorewall to look in the given directory first for configuration files. Example:shorewall refresh net2fw nat:net_dnat #Refresh the 'net2loc' chain in the filter table and the 'net_dnat' chain in the nat table The refresh command has slightly different behavior. When no chain name is given to the refresh command, the mangle table is refreshed along with the blacklist chain (if any). This allows you to modify /etc/shorewall/tcrules and install the changes using refresh. reload If directory is omitted, the current working directory is assumed. Allows a non-root user to compile a shorewall script and install it on a system (provided that the user has root access to the system via ssh). The command is equivalent to: /sbin/shorewall compile -e directory directory/firewall &&\ scp directory/firewall directory/firewall.conf root@system:/var/lib/shorewall-lite/ &&\ ssh root@system '/sbin/shorewall-lite restart' In other words, the configuration in the specified (or defaulted) directory is compiled to a file called firewall in that directory. If compilation succeeds, then firewall is copied to system using scp. If the copy succeeds, Shorewall Lite on system is restarted via ssh. If -s is specified and the restart command succeeds, then the remote Shorewall-lite configuration is saved by executing shorewall-lite save via ssh. if -c is included, the command shorewall-lite show capabilities -f > /var/lib/shorewall-lite/capabilities is executed via ssh then the generated file is copied to directory using scp. This step is performed before the configuration is compiled. If is included, it specifies that the root user on system is named root-user-name rather than "root". The option was added in Shorewall 4.5.3 and causes a Perl stack trace to be included with each compiler-generated error and warning message. reset All the packet and byte counters in the firewall are reset. restart Restart is similar to shorewall start except that it assumes that the firewall is already started. Existing connections are maintained. If a directory is included in the command, Shorewall will look in that directory first for configuration files. The option causes Shorewall to avoid updating the routing table(s). The option causes the connection tracking table to be flushed; the conntrack utility must be installed to use this option. The option causes the compiler to run under the Perl debugger. The option suppresses the compilation step and simply reused the compiled script which last started/restarted Shorewall, provided that /etc/shorewall and its contents have not been modified since the last start/restart. The option was added in Shorewall 4.4.20 and performs the compilation step unconditionally, overriding the AUTOMAKE setting in shorewall.conf(5). When both and are present, the result is determined by the option that appears last. The option was added in Shorewall 4.5.3 and causes a Perl stack trace to be included with each compiler-generated error and warning message. restore Restore Shorewall to a state saved using the shorewall save command. Existing connections are maintained. The filename names a restore file in /var/lib/shorewall created using shorewall save; if no filename is given then Shorewall will be restored from the file specified by the RESTOREFILE option in shorewall.conf(5). safe-restart Only allowed if Shorewall is running. The current configuration is saved in /var/lib/shorewall/safe-restart (see the save command below) then a shorewall restart is done. You will then be prompted asking if you want to accept the new configuration or not. If you answer "n" or if you fail to answer within 60 seconds (such as when your new configuration has disabled communication with your terminal), the configuration is restored from the saved configuration. If a directory is given, then Shorewall will look in that directory first when opening configuration files. Beginning with Shorewall 4.5.0, you may specify a different timeout value using the option. The numeric timeout may optionally be followed by an , or suffix (e.g., 5m) to specify seconds, minutes or hours respectively. If the suffix is omitted, seconds is assumed. safe-start Shorewall is started normally. You will then be prompted asking if everything went all right. If you answer "n" or if you fail to answer within 60 seconds (such as when your new configuration has disabled communication with your terminal), a shorewall clear is performed for you. If a directory is given, then Shorewall will look in that directory first when opening configuration files. Beginning with Shorewall 4.5.0, you may specify a different timeout value using the option. The numeric timeout may optionally be followed by an , or suffix (e.g., 5m) to specify seconds, minutes or hours respectively. If the suffix is omitted, seconds is assumed. save The dynamic blacklist is stored in /var/lib/shorewall/save. The state of the firewall is stored in /var/lib/shorewall/filename for use by the shorewall restore and shorewall -f start commands. If filename is not given then the state is saved in the file specified by the RESTOREFILE option in shorewall.conf(5). show The show command can have a number of different arguments: actions Produces a report about the available actions (built-in, standard and user-defined). capabilities Displays your kernel/iptables capabilities. The -f option causes the display to be formatted as a capabilities file for use with compile -e. [ [ ] chain... ] The rules in each chain are displayed using the iptables -L chain -n -v command. If no chain is given, all of the chains in the filter table are displayed. The -x option is passed directly through to iptables and causes actual packet and byte counts to be displayed. Without this option, those counts are abbreviated. The -t option specifies the Netfilter table to display. The default is filter. The -b ('brief') option causes rules which have not been used (i.e. which have zero packet and byte counts) to be omitted from the output. Chains with no rules displayed are also omitted from the output. The -l option causes the rule number for each Netfilter rule to be displayed. If the -t option and the keyword are both omitted and any of the listed chains do not exist, a usage message is displayed. classifiers|filters Displays information about the packet classifiers defined on the system as a result of traffic shaping configuration. config Displays distribution-specific defaults. connections Displays the IP connections currently being tracked by the firewall. event event Added in Shorewall 4.5.19. Displays the named event. events Added in Shorewall 4.5.19. Displays all events. ip Displays the system's IPv4 configuration. ipa Added in Shorewall 4.4.17. Displays the per-IP accounting counters (shorewall-accounting (5)). log Displays the last 20 Shorewall messages from the log file specified by the LOGFILE option in shorewall.conf(5). The -m option causes the MAC address of each packet source to be displayed if that information is available. macros Displays information about each macro defined on the firewall system. macro Added in Shorewall 4.4.6. Displays the file that implements the specified macro (usually /usr/share/shorewall/macro.macro). marks Added in Shorewall 4.4.26. Displays the various fields in packet marks giving the min and max value (in both decimal and hex) and the applicable mask (in hex). nat Displays the Netfilter nat table using the command iptables -t nat -L -n -v.The -x option is passed directly through to iptables and causes actual packet and byte counts to be displayed. Without this option, those counts are abbreviated. policies Added in Shorewall 4.4.4. Displays the applicable policy between each pair of zones. Note that implicit intrazone ACCEPT policies are not displayed for zones associated with a single network where that network doesn't specify . routing Displays the system's IPv4 routing configuration. raw Displays the Netfilter raw table using the command iptables -t raw -L -n -v.The -x option is passed directly through to iptables and causes actual packet and byte counts to be displayed. Without this option, those counts are abbreviated. tc Displays information about queuing disciplines, classes and filters. zones Displays the current composition of the Shorewall zones on the system. start Start shorewall. Existing connections through shorewall managed interfaces are untouched. New connections will be allowed only if they are allowed by the firewall rules or policies. If a directory is included in the command, Shorewall will look in that directory first for configuration files. If -f is specified, the saved configuration specified by the RESTOREFILE option in shorewall.conf(5) will be restored if that saved configuration exists and has been modified more recently than the files in /etc/shorewall. When -f is given, a directory may not be specified. Update: In Shorewall 4.4.20, a new LEGACY_FASTSTART option was added to shorewall.conf(5). When LEGACY_FASTSTART=No, the modification times of files in /etc/shorewall are compared with that of /var/lib/shorewall/firewall (the compiled script that last started/restarted the firewall). The option causes Shorewall to avoid updating the routing table(s). The option causes the connection tracking table to be flushed; the conntrack utility must be installed to use this option. The option was added in Shorewall 4.4.20 and performs the compilation step unconditionally, overriding the AUTOMAKE setting in shorewall.conf(5). When both and are present, the result is determined by the option that appears last. The option was added in Shorewall 4.5.3 and causes a Perl stack trace to be included with each compiler-generated error and warning message. stop Stops the firewall. All existing connections, except those listed in shorewall-routestopped(5) or permitted by the ADMINISABSENTMINDED option in shorewall.conf(5), are taken down. The only new traffic permitted through the firewall is from systems listed in shorewall-routestopped(5) or by ADMINISABSENTMINDED. If is given, the command will be processed by the compiled script that executed the last successful start, restart or refresh command if that script exists. status Produces a short report about the state of the Shorewall-configured firewall. try If Shorewall is started then the firewall state is saved to a temporary saved configuration (/var/lib/shorewall/.try). Next, if Shorewall is currently started then a restart command is issued using the specified configuration directory; otherwise, a start command is performed using the specified configuration directory. if an error occurs during the compilation phase of the restart or start, the command terminates without changing the Shorewall state. If an error occurs during the restart phase, then a shorewall restore is performed using the saved configuration. If an error occurs during the start phase, then Shorewall is cleared. If the start/restart succeeds and a timeout is specified then a clear or restore is performed after timeout seconds. Beginning with Shorewall 4.5.0, the numeric timeout may optionally be followed by an , or suffix (e.g., 5m) to specify seconds, minutes or hours respectively. If the suffix is omitted, seconds is assumed. update Added in Shorewall 4.4.21 and causes the compiler to update /etc/shorewall/shorewall.conf then validate the configuration. The update will add options not present in the old file with their default values, and will move deprecated options with non-defaults to a deprecated options section at the bottom of the file. Your existing shorewall.conf file is renamed shorewall.conf.bak. The option causes the updated shorewall.conf file to be annotated with documentation. The option was added in Shorewall 4.4.26 and causes legacy blacklisting rules (shorewall-blacklist (5) ) to be converted to entries in the blrules file (shorewall-blrules (5) ). The blacklist keyword is removed from shorewall-zones (5), shorewall-interfaces (5) and shorewall-hosts (5). The unmodified files are saved with a .bak suffix. The option was added in Shorewall 4.5.11. When this option is specified, the compiler will walk through the directories in the CONFIG_PATH replacing FORMAT and COMMENT entries to compiler directives (e.g., ?FORMAT and ?COMMENT. When a file is updated, the original is saved in a .bak file in the same directory. For a description of the other options, see the check command above. version Displays Shorewall's version. The option is included for compatibility with earlier Shorewall releases and is ignored. EXIT STATUS In general, when a command succeeds, status 0 is returned; when the command fails, a non-zero status is returned. The status command returns exit status as follows: 0 - Firewall is started. 3 - Firewall is stopped or cleared 4 - Unknown state; usually means that the firewall has never been started. FILES /etc/shorewall/ See ALSO http://www.shorewall.net/starting_and_stopping_shorewall.htm shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-rules.xml0000644000175000017500000023153712222401136022674 0ustar teastepteastep shorewall-rules 5 rules Shorewall rules file /etc/shorewall/rules Description Entries in this file govern connection establishment by defining exceptions to the policies laid out in shorewall-policy(5). By default, subsequent requests and responses are automatically allowed using connection tracking. For any particular (source,dest) pair of zones, the rules are evaluated in the order in which they appear in this file and the first terminating match is the one that determines the disposition of the request. All rules are terminating except LOG and COUNT rules. If you masquerade or use SNAT from a local system to the internet, you cannot use an ACCEPT rule to allow traffic from the internet to that system. You must use a DNAT rule instead. The rules file is divided into sections. Each section is introduced by a "Section Header" which is a line beginning with SECTION and followed by the section name. Sections are as follows and must appear in the order listed: ALL This section was added in Shorewall 4.4.23. Rules in this section are applied, regardless of the connection tracking state of the packet. ESTABLISHED Packets in the ESTABLISHED state are processed by rules in this section. The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG and QUEUE There is an implicit ACCEPT rule inserted at the end of this section. RELATED Packets in the RELATED state are processed by rules in this section. The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG and QUEUE There is an implicit rule added at the end of this section that invokes the RELATED_DISPOSITION (shorewall.conf(5)). INVALID Added in Shorewall 4.5.13. Packets in the INVALID state are processed by rules in this section. The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG and QUEUE. There is an implicit rule added at the end of this section that invokes the INVALID_DISPOSITION (shorewall.conf(5)). UNTRACKED Added in Shorewall 4.5.13. Packets in the UNTRACKED state are processed by rules in this section. The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG and QUEUE. There is an implicit rule added at the end of this section that invokes the UNTRACKED_DISPOSITION (shorewall.conf(5)). NEW Packets in the NEW, INVALID and UNTRACKED states are processed by rules in this section. If you are not familiar with Netfilter to the point where you are comfortable with the differences between the various connection tracking states, then it is suggested that you omit the ESTABLISHED and RELATED sections and place all of your non-blacklisting rules in the NEW section (That's after the line that reads SECTION NEW'). If you specify FASTACCEPT=Yes in shorewall.conf(5) then the ALL, ESTABLISHED and RELATED sections must be empty. An except is made if you are running Shorewall 4.4.27 or later and you have specified a non-default value for RELATED_DISPOSITION or RELATED_LOG_LEVEL. In that case, you may have rules in the RELATED section of this file. You may omit any section that you don't need. If no Section Headers appear in the file then all rules are assumed to be in the NEW section. When defining rules that rewrite the destination IP address and/or port number (namely DNAT and REDIRECT rules), it is important to keep straight which columns in the file specify the packet before rewriting and which specify how the packet will look after rewriting. The DEST column specifies the final destination for the packet after rewriting and can include the final IP address and/or port number. The remaining columns specify characteristics of the packet before rewriting. In particular, the ORIGINAL DEST column gives the original destination IP address of the packet and the DEST PORT(S) column give the original destination port(s). The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ACTION - target[:{log-level|none}[!][:tag]] Specifies the action to be taken if the connection request matches the rule. target must be one of the following. ACCEPT Allow the connection request. ACCEPT+ like ACCEPT but also excludes the connection from any subsequent matching DNAT[-] or REDIRECT[-] rules. ACCEPT! like ACCEPT but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall.conf(5). action The name of an action declared in shorewall-actions(5) or in /usr/share/shorewall/actions.std. ADD(ipset:flags) Added in Shorewall 4.4.12. Causes addresses and/or port numbers to be added to the named ipset. The flags specify the address or tuple to be added to the set and must match the type of ipset involved. For example, for an iphash ipset, either the SOURCE or DESTINATION address can be added using flags src or dst respectively (see the -A command in ipset (8)). ADD is non-terminating. Even if a packet matches the rule, it is passed on to the next rule. AUDIT[(accept|drop|reject)] Added in Shorewall 4.5.10. Audits the packet with the specified type; if the type is omitted, then is assumed. Require AUDIT_TARGET support in the kernel and iptables. A_ACCEPT, A_ACCEPT+ and A_ACCEPT! Added in Shorewall 4.4.20. Audited versions of ACCEPT, ACCEPT+ and ACCEPT! respectively. Require AUDIT_TARGET support in the kernel and iptables. A_DROP and A_DROP! Added in Shorewall 4.4.20. Audited versions of DROP and DROP! respectively. Require AUDIT_TARGET support in the kernel and iptables. A_REJECT AND A_REJECT! Added in Shorewall 4.4.20. Audited versions of REJECT and REJECT! respectively. Require AUDIT_TARGET support in the kernel and iptables. [?]COMMENT the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries. The comment will appear delimited by "/* ... */" in the output of "shorewall show <chain>". To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. CONTINUE For experts only. Do not process any of the following rules for this (source zone,destination zone). If the source and/or destination IP address falls into a zone defined later in shorewall-zones(5) or in a parent zone of the source or destination zones, then this connection request will be passed to the rules defined for that (those) zone(s). See shorewall-nesting(5) for additional information. CONTINUE! like CONTINUE but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall.conf(5). COUNT Simply increment the rule's packet and byte count and pass the packet to the next rule. DEL(ipset:flags) Added in Shorewall 4.4.12. Causes an entry to be deleted from the named ipset. The flags specify the address or tuple to be deleted from the set and must match the type of ipset involved. For example, for an iphash ipset, either the SOURCE or DESTINATION address can be deleted using flags src or dst respectively (see the -D command in ipset (8)). DEL is non-terminating. Even if a packet matches the rule, it is passed on to the next rule. DNAT Forward the request to another system (and optionally another port). DNAT- Advanced users only. Like DNAT but only generates the DNAT iptables rule and not the companion ACCEPT rule. DROP Ignore the request. DROP! like DROP but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall.conf(5). HELPER Added in Shorewall 4.5.7. This action requires that the HELPER column contains the name of the Netfilter helper to be associated with connections matching this connection. May only be specified in the NEW section and is useful for being able to specify a helper when the applicable policy is ACCEPT. No destination zone should be specified in HELPER rules. INLINE[(action)] Added in Shorewall 4.5.16. This action allows you to construct most of the rule yourself using iptables syntax. The part that you specify must follow a semicolon (';') and is completely free-form. If the target of the rule (the part following 'j') is something that Shorewall supports in the ACTION column, then you may enclose it in parentheses (e.g., INLINE(ACCEPT)). Otherwise, you can include it after the semicolon. In this case, you must declare the target as a builtin action in shorewall-actions(5). Some considerations when using INLINE: The , , , , , , and state match ( or ) matches will always appear in the front of the rule in that order. When multiple matches are specified, the compiler will keep them in the order in which they appear (excluding the above listed ones), but they will not necessarily be at the end of the generated rule. For example, if addresses are specified in the SOURCE and/or DEST columns, their generated matches will appear after those specified using ';'. LOG:level Simply log the packet and continue with the next rule. macro[(macrotarget)] The name of a macro defined in a file named macro.macro. If the macro accepts an action parameter (Look at the macro source to see if it has PARAM in the TARGET column) then the macro name is followed by the parenthesized macrotarget (ACCEPT, DROP, REJECT, ...) to be substituted for the parameter. Example: FTP(ACCEPT). The older syntax where the macro name and the target are separated by a slash (e.g. FTP/ACCEPT) is still allowed but is deprecated. NFLOG[(nflog-parameters)] Added in Shorewall 4.5.9.3. Queues matching packets to a back end logging daemon via a netlink socket then continues to the next rule. See http://www.shorewall.net/shorewall_logging.html. Similar to LOG:NFLOG[(nflog-parameters)], except that the log level is not changed when this ACTION is used in an action or macro body and the invocation of that action or macro specifies a log level. NFQUEUE[(queuenumber)] Queues the packet to a user-space application using the nfnetlink_queue mechanism. If a queuenumber is not specified, queue zero (0) is assumed. NFQUEUE![(queuenumber)] like NFQUEUE but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall.conf(5). NONAT Excludes the connection from any subsequent DNAT[-] or REDIRECT[-] rules but doesn't generate a rule to accept the traffic. QUEUE Queue the packet to a user-space application such as ftwall (http://p2pwall.sf.net). The application may reinsert the packet for further processing. QUEUE! like QUEUE but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall.conf(5). REJECT disallow the request and return an icmp-unreachable or an RST packet. REJECT! like REJECT but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall.conf(5). REDIRECT Redirect the request to a server running on the firewall. REDIRECT- Advanced users only. Like REDIRECT but only generates the REDIRECT iptables rule and not the companion ACCEPT rule. ULOG[(ulog-parameters)] Added in Shorewall 4.5.10. Queues matching packets to a back end logging daemon via a netlink socket then continues to the next rule. See http://www.shorewall.net/shorewall_logging.html. Similar to LOG:ULOG[(ulog-parameters)], except that the log level is not changed when this ACTION is used in an action or macro body and the invocation of that action or macro specifies a log level. The target may optionally be followed by ":" and a syslog log level (e.g, REJECT:info or Web(ACCEPT):debug). This causes the packet to be logged at the specified level. Note that if the ACTION involves destination network address translation (DNAT, REDIRECT, etc.) then the packet is logged before the destination address is rewritten. If the ACTION names an action declared in shorewall-actions(5) or in /usr/share/shorewall/actions.std then: If the log level is followed by "!' then all rules in the action are logged at the log level. If the log level is not followed by "!" then only those rules in the action that do not specify logging are logged at the specified level. The special log level none! suppresses logging by the action. You may also specify ULOG or NFLOG (must be in upper case) as a log level.This will log to the ULOG or NFLOG target for routing to a separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html). Actions specifying logging may be followed by a log tag (a string of alphanumeric characters) which is appended to the string generated by the LOGPREFIX (in shorewall.conf(5)). Example: ACCEPT:info:ftp would include 'ftp ' at the end of the log prefix generated by the LOGPREFIX setting. SOURCE - {zone|zone-list[+]|{all|any}[+][-]}[:interface][:{address-or-range[,address-or-range]...[exclusion]|exclusion|+ipset|^countrycode-list} Source hosts to which the rule applies. May be a zone declared in /etc/shorewall/zones, $FW to indicate the firewall itself, all, all+, all-, all+- or none. Beginning with Shorewall 4.4.13, you may use a zone-list which consists of a comma-separated list of zones declared in shorewall-zones (5). This zone-list may be optionally followed by "+" to indicate that the rule is to apply to intra-zone traffic as well as inter-zone traffic. When none is used either in the SOURCE or DEST column, the rule is ignored. all means "All Zones", including the firewall itself. all- means "All Zones, except the firewall itself". When all[-] is used either in the SOURCE or DEST column intra-zone traffic is not affected. When all+[-] is "used, intra-zone traffic is affected. Beginning with Shorewall 4.4.13, exclusion is supported -- see see shorewall-exclusion(5). Except when all[+][-] or any[+][-] is specified, clients may be further restricted to a list of networks and/or hosts by appending ":" and a comma-separated list of network and/or host addresses. Hosts may be specified by IP or MAC address; mac addresses must begin with "~" and must use "-" as a separator. The above restriction on all[+][-] and any[+][-] is removed in Shorewall-4.4.13. any is equivalent to all when there are no nested zones. When there are nested zones, any only refers to top-level zones (those with no parent zones). Note that any excludes all vserver zones, since those zones are nested within the firewall zone. Hosts may also be specified as an IP address range using the syntax lowaddress-highaddress. This requires that your kernel and iptables contain iprange match support. If your kernel and iptables have ipset match support then you may give the name of an ipset prefaced by "+". The ipset name may be optionally followed by a number from 1 to 6 enclosed in square brackets ([]) to indicate the number of levels of source bindings to be matched. Beginning with Shorewall 4.4.17, the primary IP address of a firewall interface can be specified by an ampersand ('&') followed by the logical name of the interface as found in the INTERFACE column of shorewall-interfaces (5). Beginning with Shorewall 4.5.4, A countrycode-list may be specified. A countrycode-list is a comma-separated list of up to 15 two-character ISO-3661 country codes enclosed in square brackets ('[...]') and preceded by a caret ('^'). When a single country code is given, the square brackets may be omitted. A list of country codes supported by Shorewall may be found at http://www.shorewall.net/ISO-3661.html. Specifying a countrycode-list requires GeoIP Match support in your iptables and Kernel. You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion(5)). Examples: dmz:192.168.2.2 Host 192.168.2.2 in the DMZ net:155.186.235.0/24 Subnet 155.186.235.0/24 on the Internet loc:192.168.1.1,192.168.1.2 Hosts 192.168.1.1 and 192.168.1.2 in the local zone. loc:~00-A0-C9-15-39-78 Host in the local zone with MAC address 00:A0:C9:15:39:78. net:192.0.2.11-192.0.2.17 Hosts 192.0.2.11-192.0.2.17 in the net zone. net:!192.0.2.11-192.0.2.17 All hosts in the net zone except for 192.0.2.11-192.0.2.17. net:155.186.235.0/24!155.186.235.16/28 Subnet 155.186.235.0/24 on the Internet except for 155.186.235.16/28 $FW:&eth0 The primary IP address of eth0 in the firewall zone (Shorewall 4.4.17 and later). DEST - {zone|zone-list[+]|{all|any}[+][-]}[:{interface|address-or-range[,address-or-range]...[exclusion]|exclusion|+ipset|^countrycode-list}][port[:random]] Location of Server. May be a zone declared in shorewall-zones(5), $FW to indicate the firewall itself, all. all+ or none. Beginning with Shorewall 4.4.13, you may use a zone-list which consists of a comma-separated list of zones declared in shorewall-zones (5). This zone-list may be optionally followed by "+" to indicate that the rule is to apply to intra-zone traffic as well as inter-zone traffic. Beginning with Shorewall 4.5.4, A countrycode-list may be specified. A countrycode-list is a comma-separated list of up to 15 two-character ISO-3661 country codes enclosed in square brackets ('[...]') and preceded by a caret ('^'). When a single country code is given, the square brackets may be omitted. A list of country codes supported by Shorewall may be found at http://www.shorewall.net/ISO-3661.html. Specifying a countrycode-list requires GeoIP Match support in your iptables and Kernel. When none is used either in the SOURCE or DEST column, the rule is ignored. When all is used either in the SOURCE or DEST column intra-zone traffic is not affected. When all+ is used, intra-zone traffic is affected. Beginning with Shorewall 4.4.13, exclusion is supported -- see see shorewall-exclusion(5). any is equivalent to all when there are no nested zones. When there are nested zones, any only refers to top-level zones (those with no parent zones). The zone should be omitted in DNAT-, REDIRECT- and NONAT rules. If the DEST zone is a bport zone, then either: the SOURCE must be , or the SOURCE zone must be another bport zone associated with the same bridge, or the SOURCE zone must be an ipv4 zone that is associated with only the same bridge. Except when all[+]|[-] is specified, the server may be further restricted to a particular network, host or interface by appending ":" and the network, host or interface. See SOURCE above. You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion(5)). Restriction: MAC addresses are not allowed (this is a Netfilter restriction). Like in the SOURCE column, you may specify a range of IP addresses using the syntax lowaddress-highaddress. When the ACTION is DNAT or DNAT-, the connections will be assigned to addresses in the range in a round-robin fashion. If you kernel and iptables have ipset match support then you may give the name of an ipset prefaced by "+". The ipset name may be optionally followed by a number from 1 to 6 enclosed in square brackets ([]) to indicate the number of levels of destination bindings to be matched. Only one of the SOURCE and DEST columns may specify an ipset name. Beginning with Shorewall 4.4.17, the primary IP address of a firewall interface can be specified by an ampersand ('&') followed by the logical name of the interface as found in the INTERFACE column of shorewall-interfaces (5). The port that the server is listening on may be included and separated from the server's IP address by ":". If omitted, the firewall will not modify the destination port. A destination port may only be included if the ACTION is DNAT or REDIRECT. Example: loc:192.168.1.3:3128 specifies a local server at IP address 192.168.1.3 and listening on port 3128. The port may be specified as a service name. You may specify a port range in the form lowport-highport to cause connections to be assigned to ports in the range in round-robin fashion. When a port range is specified, lowport and highport must be given as integers; service names are not permitted. Additionally, the port range may be optionally followed by :random which causes assignment to ports in the list to be random. If the ACTION is REDIRECT or REDIRECT-, this column needs only to contain the port number on the firewall that the request should be redirected to. That is equivalent to specifying ::port. PROTO- {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all} Optional Protocol - ipp2p* requires ipp2p match support in your kernel and iptables. tcp:syn implies tcp plus the SYN flag must be set and the RST,ACK and FIN flags must be reset. Beginning with Shorewall 4.4.19, this column can contain a comma-separated list of protocol-numbers and/or protocol names. DEST PORT(S) (dport) - {-|port-name-number-or-range[,port-name-number-or-range]...} Optional destination Ports. A comma-separated list of Port names (from services(5)), port numbers or port ranges; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). ICMP types may be specified as a numeric type, a numeric type and code separated by a slash (e.g., 3/4), or a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP. Note that prior to Shorewall 4.4.19, only a single ICMP type may be listed. If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example bit for bit-torrent). If no port is given, ipp2p is assumed. A port range is expressed as lowport:highport. This column is ignored if PROTO = all but must be entered if any of the following columns are supplied. In that case, it is suggested that this field contain a dash (-). If your kernel contains multi-port match support, then only a single Netfilter rule will be generated if in this list and the CLIENT PORT(S) list below: 1. There are 15 or less ports listed. 2. No port ranges are included or your kernel and iptables contain extended multi-port match support. SOURCE PORT(S) (sport) - {-|port-name-number-or-range[,port-name-number-or-range]...} Optional port(s) used by the client. If omitted, any source port is acceptable. Specified as a comma- separated list of port names, port numbers or port ranges. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel. Unless you really understand IP, you should leave this column empty or place a dash (-) in the column. Most people who try to use this column get it wrong. If you don't want to restrict client ports but need to specify an ORIGINAL DEST in the next column, then place "-" in this column. If your kernel contains multi-port match support, then only a single Netfilter rule will be generated if in this list and the DEST PORT(S) list above: 1. There are 15 or less ports listed. 2. No port ranges are included or your kernel and iptables contain extended multi-port match support. ORIGINAL DEST (origdest) - [-|address[,address]...[exclusion]|exclusion] Optional. If ACTION is DNAT[-] or REDIRECT[-] then if this column is included and is different from the IP address given in the DEST column, then connections destined for that address will be forwarded to the IP and port specified in the DEST column. A comma-separated list of addresses may also be used. This is most useful with the REDIRECT target where you want to redirect traffic destined for particular set of hosts. Finally, if the list of addresses begins with "!" (exclusion) then the rule will be followed only if the original destination address in the connection request does not match any of the addresses listed. Beginning with Shorewall 4.4.17, the primary IP address of a firewall interface can be specified by an ampersand ('&') followed by the logical name of the interface as found in the INTERFACE column of shorewall-interfaces (5). For other actions, this column may be included and may contain one or more addresses (host or network) separated by commas. Address ranges are not allowed. When this column is supplied, rules are generated that require that the original destination address matches one of the listed addresses. This feature is most useful when you want to generate a filter rule that corresponds to a DNAT- or REDIRECT- rule. In this usage, the list of addresses should not begin with "!". It is also possible to specify a set of addresses then exclude part of those addresses. For example, 192.168.1.0/24!192.168.1.16/28 specifies the addresses 192.168.1.0-182.168.1.15 and 192.168.1.32-192.168.1.255. See shorewall-exclusion(5). See http://shorewall.net/PortKnocking.html for an example of using an entry in this column with a user-defined action rule. RATE LIMIT (rate) - [-|[{s|d}:[[name]:]]]rate/{sec|min|hour|day}[:burst] You may optionally rate-limit the rule by placing a value in this column: rate is the number of connections per interval (sec or min) and burst is the largest burst permitted. If no burst is given, a value of 5 is assumed. There may be no no white-space embedded in the specification. Example: 10/sec:20 When or is specified, the rate applies per source IP address or per destination IP address respectively. The name may be chosen by the user and specifies a hash table to be used to count matching connections. If not given, the name shorewallN (where N is a unique integer) is assumed. Where more than one rule specifies the same name, the connections counts for the rules are aggregated and the individual rates apply to the aggregated count. Example: s:ssh:3/min:5 USER/GROUP (user) - [!][user-name-or-number][:group-name-or-number][,...] This optional column may only be non-empty if the SOURCE is the firewall itself. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given). Beginning with Shorewall 4.5.8, multiple user or group names/ids separated by commas may be specified. Examples: joe program must be run by joe :kids program must be run by a member of the 'kids' group !:kids program must not be run by a member of the 'kids' group 2001-2099 UIDs 2001 through 2099 (Shorewall 4.5.6 and later) MARK - [!]value[/mask][:C] Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. CONNLIMIT - [!]limit[:mask] May be used to limit the number of simultaneous connections from each individual host to limit connections. Requires connlimit match in your kernel and iptables. While the limit is only checked on rules specifying CONNLIMIT, the number of current connections is calculated over all current connections from the SOURCE host. By default, the limit is applied to each host but can be made to apply to networks of hosts by specifying a mask. The mask specifies the width of a VLSM mask to be applied to the source address; the number of current connections is then taken over all hosts in the subnet source-address/mask. When is specified, the rule matches when the number of connection exceeds the limit. TIME - timeelement[&timeelement...] May be used to limit the rule to a particular time period each day, to particular days of the week or month, or to a range defined by dates and times. Requires time match support in your kernel and iptables. timeelement may be: timestart=hh:mm[:ss] Defines the starting time of day. timestop=hh:mm[:ss] Defines the ending time of day. 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. HEADERS Added in Shorewall 4.4.15. Not used in IPv4 configurations. If you with to supply a value for one of the later columns, enter '-' in this column. SWITCH - [!]switch-name[={0|1}] Added in Shorewall 4.4.24 and allows enabling and disabling the rule without requiring shorewall restart. The rule is enabled if the value stored in /proc/net/nf_condition/switch-name is 1. The rule is disabled if that file contains 0 (the default). If '!' is supplied, the test is inverted such that the rule is enabled if the file contains 0. Within the switch-name, '@0' and '@{0}' are replaced by the name of the chain to which the rule is a added. The switch-name (after '@...' expansion) must begin with a letter and be composed of letters, decimal digits, underscores or hyphens. Switch names must be 30 characters or less in length. Switches are normally off. To turn a switch on: echo 1 > /proc/net/nf_condition/switch-name To turn it off again: echo 0 > /proc/net/nf_condition/switch-name Switch settings are retained over shorewall restart. Beginning with Shorewall 4.5.10, when the switch-name is followed by or , then the switch is initialized to off or on respectively by the start command. Other commands do not affect the switch setting. HELPER - [helper] Added in Shorewall 4.5.7. In the NEW section, causes the named conntrack helper to be associated with this connection; the contents of this column are ignored unless ACTION is ACCEPT*, DNAT* or REDIRECT*. In the RELATED section, will only match if the related connection has the named helper associated with it. The helper may be one of: If the HELPERS option is specified in shorewall.conf(5), then any module specified in this column must be listed in the HELPERS setting. Examples Example 1: Accept SMTP requests from the DMZ to the internet #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST ACCEPT dmz net tcp smtp Example 2: Forward all ssh and http connection requests from the internet to local system 192.168.1.3 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST DNAT net loc:192.168.1.3 tcp ssh,http Example 3: Forward all http connection requests from the internet to local system 192.168.1.3 with a limit of 3 per second and a maximum burst of 10 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE # PORT PORT(S) DEST LIMIT DNAT net loc:192.168.1.3 tcp http - - 3/sec:10 Example 4: Redirect all locally-originating www connection requests to port 3128 on the firewall (Squid running on the firewall system) except when the destination address is 192.168.2.2 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST REDIRECT loc 3128 tcp www - !192.168.2.2 Example 5: All http requests from the internet to address 130.252.100.69 are to be forwarded to 192.168.1.3 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69 Example 6: You want to accept SSH connections to your firewall only from internet IP addresses 130.252.100.69 and 130.252.100.70 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST ACCEPT net:130.252.100.69,130.252.100.70 $FW \ tcp 22 Example 7: You wish to accept connections from the internet to your firewall on port 2222 and you want to forward them to local system 192.168.1.3, port 22 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST DNAT net loc:192.168.1.3:22 tcp 2222 Example 8: You want to redirect connection requests to port 80 randomly to the port range 81-90. #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST REDIRECT net $FW::81-90:random tcp www Example 9: Shorewall does not impose as much structure on the Netfilter rules in the 'nat' table as it does on those in the filter table. As a consequence, when using Shorewall versions before 4.1.4, care must be exercised when using DNAT and REDIRECT rules with zones defined with wildcard interfaces (those ending with '+'. Here is an example: shorewall-zones(8): #ZONE TYPE OPTIONS fw firewall net ipv4 dmz ipv4 loc ipv4 shorewall-interfaces(8): #ZONE INTERFACE BROADCAST OPTIONS net ppp0 loc eth1 detect dmz eth2 detect - ppp+ # Addresses are assigned from 192.168.3.0/24 shorewall-host(8): #ZONE HOST(S) OPTIONS loc ppp+:192.168.3.0/24 rules: #ACTION SOURCE DEST PROTO DEST # PORT(S) REDIRECT loc 3128 tcp 80 Note that it would have been tempting to simply define the loc zone entirely in shorewall-interfaces(8): #******************* INCORRECT ***************** #ZONE INTERFACE BROADCAST OPTIONS net ppp0 loc eth1 detect loc ppp+ dmz eth2 This would have made it impossible to run a internet-accessible web server in the DMZ because all traffic entering ppp+ interfaces would have been redirected to port 3128 on the firewall and there would have been no net->fw ACCEPT rule for that traffic. Example 10: Add the tuple (source IP, dest port, dest IP) of an incoming SSH connection to the ipset S: #ACTION SOURCE DEST PROTO DEST # PORT(S) ADD(+S:dst,src,dst) net fw tcp 22 Example 11: You wish to limit SSH connections from remote systems to 1/min with a burst of three (to allow for limited retry): #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE # PORT(S) PORT(S) DEST LIMIT SSH(ACCEPT) net all - - - - s:1/min:3 Example 12: Forward port 80 to dmz host $BACKUP if switch 'primary_down' is on. #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH # PORT(S) PORT(S) DEST LIMIT GROUP DNAT net dmz:$BACKUP tcp 80 - - - - - - - - primary_down Example 13: Drop all email from the Anonymous Proxy and Satellite Provider address ranges: #ACTION SOURCE DEST PROTO DEST # PORT(S) DROP net:^A1,A2 fw tcp 25 Example 14: You want to generate your own rule involving iptables targets and matches not supported by Shorewall. #ACTION SOURCE DEST PROTO DEST # PORT(S) INLINE $FW net ; -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3 The above will generate the following iptables-restore input: -A fw2net -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3 Note that SECCTX must be defined as a builtin action in shorewall-actions(5): #ACTION OPTIONS SECCTX builtin FILES /etc/shorewall/rules See ALSO http://www.shorewall.net/ipsets.html http://www.shorewall.net/configuration_file_basics.htm#Pairs http://www.shorewall.net/shorewall_logging.html shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-blrules(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-secmarks.xml0000644000175000017500000003702312222401136023344 0ustar teastepteastep shorewall-secmarks 5 secmarks Shorewall file /etc/shorewall/secmarks Description Unlike rules in the shorewall-rules(5) file, evaluation of rules in this file will continue after a match. So the final secmark for each packet will be the one assigned by the LAST rule that matches. The secmarks file is used to associate an SELinux context with packets. It was added in Shorewall version 4.4.13. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). SECMARK - {SAVE|RESTORE|context|COMMENT comment} SAVE If an SELinux context is associated with the packet, the context is saved in the connection. Normally, the remaining columns should be left blank. RESTORE If an SELinux context is not currently associated with the packet, then the saved context (if any) is associated with the packet. Normally, the remaining columns should be left blank. context An SELinux context. [?]COMMENT The remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word COMMENT. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. CHAIN:STATE (chain) - {P|I|F|O|T}[:{N|I|U|IU|NI|NU|NIU|NUI:E|ER}] This column determines the CHAIN where the SELinux context is to be applied: P - PREROUTING I - INPUT F - FORWARD O - OUTPUT T - POSTROUTING It may be optionally followed by a colon and an indication of the Netfilter connection state(s) at which the context is to be applied: :N - NEW connection :I - INVALID connection :NI - NEW or INVALID connection :E - ESTABLISHED connection :ER - ESTABLISHED or RELATED connection Beginning with Shorewall 4.5.10, the following additional options are available :U - UNTRACKED connection :IU - INVALID or UNTRACKED connection :NU - NEW or UNTRACKED connection :NIU - NEW, INVALID or UNTRACKED connection. SOURCE - {-interface|[interface:]address-or-range[,address-or-range]...}[exclusion] May be: An interface name - matches traffic entering the firewall on the specified interface. May not be used in classify rules or in rules using the T in the CHAIN column. A comma-separated list of host or network IP addresses or MAC addresses. An interface name followed by a colon (":") followed by a comma-separated list of host or network IP addresses or MAC addresses. MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion(5)). Addresses may be specified using an ipset name preceded by '+'. DEST - {-|{interface|[interface:]address-or-range[,address-or-range]...}[exclusion] May be: An interface name. May not be used in the PREROUTING or INPUT chains. The interface name may be optionally followed by a colon (":") and an IP address list. A comma-separated list of host or network IP addresses. The list may include ip address ranges if your kernel and iptables include iprange support. You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion(5)). Addresses may be specified using an ipset name preceded by '+'. PROTO - {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}[,...] Protocol - ipp2p requires ipp2p match support in your kernel and iptables. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. PORT(S) (dport) - [-|port-name-number-or-range[,port-name-number-or-range]...] Optional destination Ports. A comma-separated list of Port names (from services(5)), port numbers or port ranges; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). ICMP types may be specified as a numeric type, a numeric type and code separated by a slash (e.g., 3/4), or a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP. If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example bit for bit-torrent). If no PORT is given, ipp2p is assumed. This column is ignored if PROTOCOL = all but must be entered if any of the following field is supplied. In that case, it is suggested that this field contain "-" SOURCE PORT(S) (sport) - [-|port-name-number-or-range[,port-name-number-or-range]...] Optional source port(s). If omitted, any source port is acceptable. Specified as a comma-separated list of port names, port numbers or port ranges. USER - [!][user-name-or-number][:group-name-or-number] This optional column may only be non-empty if the SOURCE is the firewall itself. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given). Examples: joe program must be run by joe :kids program must be run by a member of the 'kids' group !:kids program must not be run by a member of the 'kids' group MARK - [!]value[/mask][:C] Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. EXAMPLE Mark the first incoming packet of a connection on the loopback interface and destined for address 127.0.0.1 and tcp port 3306 with context system_u:object_r:mysqld_t:s0 and save that context in the conntrack table. On subsequent input packets in the connection, set the context from the conntrack table. /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS - lo - ignore /etc/shorewall/secmarks: #SECMARK CHAIN: SOURCE DEST PROTO DEST SOURCE USER/ MARK # STATE PORT(S) PORT(S) GROUP system_u:object_r:mysqld_packet_t:s0 I:N lo 127.0.0.1 tcp 3306 SAVE I:N lo 127.0.0.1 tcp 3306 RESTORE I:ER FILES /etc/shorewall/secmarks See ALSO http://james-morris.livejournal.com/11010.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-accounting.xml0000644000175000017500000007616212222401136023675 0ustar teastepteastep shorewall-accounting 5 accounting Shorewall Accounting file /etc/shorewall/accounting Description Accounting rules exist simply to count packets and bytes in categories that you define in this file. You may display these rules and their packet and byte counters using the shorewall show accounting command. Beginning with Shorewall 4.4.18, the accounting structure can be created with three root chains: accountin: Rules that are valid in the INPUT chain (may not specify an output interface). accountout: Rules that are valid in the OUTPUT chain (may not specify an input interface or a MAC address). accounting: Other rules. The new structure is enabled by sectioning the accounting file in a manner similar to the rules file. The sections are INPUT, OUTPUT and FORWARD and must appear in that order (although any of them may be omitted). The first non-commentary record in the accounting file must be a section header when sectioning is used. If sections are not used, the Shorewall rules compiler cannot detect certain violations of netfilter restrictions. These violations can result in run-time errors such as the following:
iptables-restore v1.4.13: Can't use -o with INPUT
Beginning with Shorewall 4.4.20, the ACCOUNTING_TABLE setting was added to shorewall.conf and shorewall6.conf. That setting determines the Netfilter table (filter or mangle) where the accounting rules are added. When ACCOUNTING_TABLE=mangle is specified, the available sections are PREROUTING, INPUT, OUTPUT, FORWARD and POSTROUTING. Section headers have the form: section-name When sections are enabled: A jump to a user-defined accounting chain must appear before entries that add rules to that chain. This eliminates loops and unreferenced chains. An output interface may not be specified in the PREROUTING and INPUT sections. In the OUTPUT and POSTROUTING sections: An input interface may not be specified Jumps to a chain defined in the INPUT or PREROUTING sections that specifies an input interface are prohibited MAC addresses may not be used Jump to a chain defined in the INPUT or PREROUTING section that specifies a MAC address are prohibited. The default value of the CHAIN column is: accountin in the INPUT section accountout in the OUTPUT section accountfwd in the FORWARD section accountpre in the PREROUTING section accountpost in the POSTROUTING section Traffic addressed to the firewall goes through the rules defined in the INPUT section. Traffic originating on the firewall goes through the rules defined in the OUTPUT section. Traffic being forwarded through the firewall goes through the rules from the FORWARD sections. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax): ACTION - {COUNT|DONE|chain[:{COUNT|JUMP}]|ACCOUNT(table,network)|[?]COMMENT comment} What to do when a matching packet is found. COUNT Simply count the match and continue with the next rule DONE Count the match and don't attempt to match any other accounting rules in the chain specified in the CHAIN column. chain[:COUNT] Where chain is the name of a chain; shorewall will create the chain automatically if it doesn't already exist. If a second chain is mentioned in the CHAIN column, then a jump from this second chain to chain is created. If no chain is named in the CHAIN column, then a jump from the default chain to chain is created. If :COUNT is included, a counting rule matching this entry will be added to chain. The chain may not exceed 29 characters in length and may be composed of letters, digits, dash ('-') and underscore ('_'). chain:JUMP Like the previous option without the :COUNT part. ACCOUNT(table,network) This action implements per-IP accounting and was added in Shorewall 4.4.17. Requires the ACCOUNT Target capability in your iptables and kernel (see the output of shorewall show capabilities). table is the name of an accounting table (you choose the name). All rules specifying the same name will have their per-IP counters accumulated in the same table. network is an IPv4 network in CIDR notation (e.g., 192.168.1.0/24). The network can be as large as a /8 (class A). One nice feature of per-IP accounting is that the counters survive shorewall restart. This has a downside, however. If you change the network associated with an accounting table, then you must shorewall stop; shorewall start to have a successful restart (counters will be cleared). The counters in a table are printed using the iptaccount utility. For a command synopsis, type: iptaccount --help As of February 2011, the ACCOUNT Target capability and the iptaccount utility are only available when xtables-addons is installed. See http://www.shorewall.net/Accounting.html#perIP for additional information. INLINE Added in Shorewall 4.5.16. Allows free form iptables matches to be specified following a ';'. In the generated iptables rule(s), the free form matches will follow any matches that are generated by the column contents. NFACCT({object[!]}[,...]) Added in Shorewall 4.5.7. Provides a form of accounting that survives shorewall stop/shorewall start and shorewall restart. Requires the NFaccnt Match capability in your kernel and iptables. object names an nfacct object (see man nfaccnt(8)). Multiple rules can specify the same object; all packets that match any of the rules increment the packet and bytes count of the object. Prior to Shorewall 4.5.16, only one object could be specified. Beginning with Shorewall 4.5.16, an arbitrary number of objects may be given. With Shorewall 4.5.16 or later, an nfacct object in the list may optionally be followed by ! to indicate that the nfacct object will be incremented unconditionally for each packet. When ! is omitted, the object will be incremented only if all of the matches in the rule succeed. NFLOG[(nflog-parameters)] - Added in Shorewall-4.4.20. Causes each matching packet to be sent via the currently loaded logging back-end (usually nfnetlink_log) where it is available to accounting daemons through a netlink socket. [?]COMMENT The remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word COMMENT. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. CHAIN - {-|chain} The name of a chain. If specified as - the accounting chain is assumed when the file is un-sectioned. When the file is sectioned, the default is one of accountin, accountout, etc. depending on the section. This is the chain where the accounting rule is added. The chain will be created if it doesn't already exist. The chain may not exceed 29 characters in length. SOURCE - {-|any|all|interface|interface:address|address} Packet Source. The name of an interface, an address (host or net) or an interface name followed by ":" and a host or net address. An ipset name is also accepted as an address. DESTINATION (dest) - {-|any|all|interface|interface:address|address} Packet Destination. Format same as SOURCE column. PROTOCOL (proto) - {-|{any|all|protocol-name|protocol-number|ipp2p[:{udp|all}]}[,...]} A protocol-name (from protocols(5)), a protocol-number, ipp2p, ipp2p:udp or ipp2p:all Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. DEST PORT(S) (dport) - {-|any|all|ipp2p-option|port-name-or-number[,port-name-or-number]...} Destination Port number. Service name from services(5) or port number. May only be specified if the protocol is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136). You may place a comma-separated list of port names or numbers in this column if your kernel and iptables include multi-port match support. If the PROTOCOL is ipp2p then this column must contain an ipp2p-option ("iptables -m ipp2p --help") without the leading "--". If no option is given in this column, ipp2p is assumed. SOURCE PORT(S) (sport)- {-|any|all|port-name-or-number[,port-name-or-number]...} Service name from services(5) or port number. May only be specified if the protocol is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136). You may place a comma-separated list of port numbers in this column if your kernel and iptables include multi-port match support. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel. USER/GROUP (user) - [!][user-name-or-number][:group-name-or-number][+program-name] This column may only be non-empty if the CHAIN is OUTPUT. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given). Examples: joe program must be run by joe :kids program must be run by a member of the 'kids' group !:kids program must not be run by a member of the 'kids' group +upnpd #program named upnpd The ability to specify a program name was removed from Netfilter in kernel version 2.6.14. MARK - [!]value[/mask][:C] Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. IPSEC - option-list (Optional - Added in Shorewall 4.4.13 but broken until 4.5.4.1 ) The option-list consists of a comma-separated list of options from the following list. Only packets that will be encrypted or have been decrypted via an SA that matches these options will have their source address changed. reqid=number where number is specified using setkey(8) using the 'unique:number option for the SPD level. spi=<number> where number is the SPI of the SA used to encrypt/decrypt packets. proto=ah|esp|ipcomp IPSEC Encapsulation Protocol mss=number sets the MSS field in TCP packets mode=transport|tunnel IPSEC mode tunnel-src=address[/mask] only available with mode=tunnel tunnel-dst=address[/mask] only available with mode=tunnel strict Means that packets must match all rules. next Separates rules; can only be used with strict yes or ipsec When used by itself, causes all traffic that will be encrypted/encapsulated or has been decrypted/un-encapsulated to match the rule. no or none When used by itself, causes all traffic that will not be encrypted/encapsulated or has been decrypted/un-encapsulated to match the rule. in May only be used in the FORWARD section and must be the first or the only item the list. Indicates that matching packets have been decrypted in input. out May only be used in the FORWARD section and must be the first or the only item in the list. Indicates that matching packets will be encrypted on output. If this column is non-empty and sections are not used, then: A chain NAME appearing in the ACTION column must be a chain branched either directly or indirectly from the accipsecin or accipsecout chain. The CHAIN column must contain either accipsecin or accipsecout or a chain branched either directly or indirectly from those chains. These rules will NOT appear in the accounting chain. In all of the above columns except ACTION and CHAIN, the values -, any and all may be used as wildcard'gs. Omitted trailing columns are also treated as wildcard'g.
FILES /etc/shorewall/accounting See ALSO http://shorewall.net/Accounting.html http://shorewall.net/shorewall_logging.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tcfilters.xml0000644000175000017500000002656312222401136023542 0ustar teastepteastep shorewall-tcfilters 5 tcfilters Shorewall u32 classifier rules file /etc/shorewall/tcfilters Description Entries in this file cause packets to be classified for traffic shaping. Beginning with Shorewall 4.4.15, the file may contain entries for both IPv4 and IPv6. By default, all rules apply to IPv4 but that can be changed by inserting a line as follows: IPV4 Following entries apply to IPv4. IPV6 Following entries apply to IPv6 ALL Following entries apply to both IPv4 and IPv6. Each entry is processed twice; once for IPv4 and once for IPv6. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). CLASS - interface:class The name or number of an interface defined in shorewall-tcdevices(5) followed by a class number defined for that interface in shorewall-tcclasses(5). SOURCE - {-|address} Source of the packet. May be a host or network address. DNS names are not allowed. DEST - {-|address}} Destination of the packet. May be a host or network address. DNS names are not allowed. You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion(5)). PROTO - {-|{protocol-number|protocol-name|all}[,...]} Protocol. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. DEST PORT (dport) - [-|port-name-or-number] Optional destination Ports. A Port name (from services(5)) or a port number; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). SOURCE PORT (sport) - [-|port-name-or-number] Optional source port. TOS (Optional) - [-|tos] Specifies the value of the TOS field. The tos value can be any of the following: hex-number hex-number/hex-number The hex-numbers must be exactly two digits (e.g., 0x04)x. LENGTH - [-|number] Optional - Must be a power of 2 between 32 and 8192 inclusive. Packets with a total length that is strictly less than the specified number will match the rule. PRIORITY - [-|priority] Added in Shorewall 4.5.8. Specifies the rule priority. The priority value must be > 0 and <= 65535. When a priority is not given: For Shorewall versions prior to 4.5.8 - all filters have priority 10. For Shorewall 4.5.8 and later - for each device, the compiler maintains a high-water priority with an initial value of 0. When a filter has no priority, the high-water priority is incremented by 1 and assigned to the filter. When a priority greater than the high-water priority is entered in this column, the high-water priority is set to the specified priority. An attempt to assign a priority value greater than 65535 (explicitly or implicitly) raises an error. The default priority values used by other Shorewall-generated filters are as follows: Classify by packet mark - ( class priority << 8 ) | 20. Ingress policing - 10 Simple TC ACK packets - 1 Complex TC ACK packets - ( class priority << 8 ) | 10. Classify by TOS - ( class priority << 8 ) | 15. Class with 'occurs' - 65535 Example Example 1: Place all 'ping' traffic on interface 1 in class 10. Note that ALL cannot be used because IPv4 ICMP and IPv6 ICMP are two different protocols. #CLASS SOURCE DEST PROTO DEST # PORT IPV4 1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-reply IPV6 1:10 ::/0 ::/0 icmp6 echo-request 1:10 ::/0 ::/0 icmp6 echo-reply Example 2: Add two filters with priority 10 (Shorewall 4.5.8 or later). #CLASS SOURCE DEST PROTO DEST PRIORITY # PORT IPV4 1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-request 10 1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 10 FILES /etc/shorewall/tcfilters See ALSO http://shorewall.net/traffic_shaping.htm http://shorewall.net/MultiISP.html http://shorewall.net/PacketMarking.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-ecn(5), shorewall-exclusion(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-blacklist.xml0000644000175000017500000001733512222401136023510 0ustar teastepteastep shorewall-blacklist 5 blacklist Shorewall Blacklist file /etc/shorewall/blacklist Description The blacklist file is used to perform static blacklisting by source address (IP or MAC), or by application. The use of this file is deprecated and beginning with Shorewall 4.5.7, the file is no longer installed. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ADDRESS/SUBNET (networks) - {-|~mac-address|ip-address|address-range|+ipset} Host address, network address, MAC address, IP address range (if your kernel and iptables contain iprange match support) or ipset name prefaced by "+" (if your kernel supports ipset match). Exclusion (shorewall-exclusion(5)) is supported. MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 A dash ("-") in this column means that any source address will match. This is useful if you want to blacklist a particular application using entries in the PROTOCOL and PORTS columns. PROTOCOL (proto) - {-|[!]protocol-number|[!]protocol-name} Optional - If specified, must be a protocol number or a protocol name from protocols(5). PORTS - {-|[!]port-name-or-number[,port-name-or-number]...} Optional - may only be specified if the protocol is TCP (6) or UDP (17). A comma-separated list of destination port numbers or service names from services(5). OPTIONS - {-|{dst|src|whitelist|audit}[,...]} Optional - added in 4.4.12. If specified, indicates whether traffic from ADDRESS/SUBNET (src) or traffic to ADDRESS/SUBNET (dst) should be blacklisted. The default is src. If the ADDRESS/SUBNET column is empty, then this column has no effect on the generated rule. In Shorewall 4.4.12, the keywords from and to were used in place of src and dst respectively. Blacklisting was still restricted to traffic arriving on an interface that has the 'blacklist' option set. So to block traffic from your local network to an internet host, you had to specify on your internal interface in shorewall-interfaces (5). Beginning with Shorewall 4.4.13, entries are applied based on the blacklist setting in shorewall-zones(5): 'blacklist' in the OPTIONS or IN_OPTIONS column. Traffic from this zone is passed against the entries in this file that have the src option (specified or defaulted). 'blacklist' in the OPTIONS or OUT_OPTIONS column. Traffic to this zone is passed against the entries in this file that have the dst option. In Shorewall 4.4.20, the whitelist option was added. When whitelist is specified, packets/connections that match the entry are not matched against the remaining entries in the file. The audit option was also added in 4.4.20 and causes packets matching the entry to be audited. The audit option may not be specified in whitelist entries and require AUDIT_TARGET support in the kernel and iptables. Example Example 1: To block DNS queries from address 192.0.2.126: #ADDRESS/SUBNET PROTOCOL PORT 192.0.2.126 udp 53 Example 2: To block some of the nuisance applications: #ADDRESS/SUBNET PROTOCOL PORT - udp 1024:1033,1434 - tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898 FILES /etc/shorewall/blacklist See ALSO http://shorewall.net/blacklisting_support.htm http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-routestopped.xml0000644000175000017500000002070512222401136024270 0ustar teastepteastep shorewall-routestopped 5 routestopped The Shorewall file that governs what traffic flows through the firewall while it is in the 'stopped' state. /etc/shorewall/routestopped Description This file is deprecated in favor of the shorewall-stoppedrules(5) file. This file is used to define the hosts that are accessible when the firewall is stopped or is being stopped. Changes to this file do not take effect until after the next shorewall start or shorewall restart command. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). INTERFACE - interface Interface through which host(s) communicate with the firewall HOST(S) (hosts) - [-|address[,address]...] Optional. Comma-separated list of IP/subnet addresses. If your kernel and iptables include iprange match support, IP address ranges are also allowed. If left empty or supplied as "-", 0.0.0.0/0 is assumed. OPTIONS - [-|option[,option]...] Optional. A comma-separated list of options. The order of the options is not important but the list can contain no embedded white-space. The currently-supported options are: routeback Set up a rule to ACCEPT traffic from these hosts back to themselves. Beginning with Shorewall 4.4.9, this option is automatically set if routeback is specified in shorewall-interfaces (5) or if the rules compiler detects that the interface is a bridge. source Allow traffic from these hosts to ANY destination. Without this option or the dest option, only traffic from this host to other listed hosts (and the firewall) is allowed. If source is specified then routeback is redundant. dest Allow traffic to these hosts from ANY source. Without this option or the source option, only traffic from this host to other listed hosts (and the firewall) is allowed. If dest is specified then routeback is redundant. notrack The traffic will be exempted from connection tracking. PROTO (Optional) ‒ protocol-name-or-number Protocol. DEST PORT(S) (dport) ‒ service-name/port-number-list Optional. A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. SOURCE PORT(S) (sport) ‒ service-name/port-number-list Optional. A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel. The source and dest options work best when used in conjunction with ADMINISABSENTMINDED=Yes in shorewall.conf(5). Example Example 1: #INTERFACE HOST(S) OPTIONS PROTO DEST SOURCE # PORT(S) PORT(S) eth2 192.168.1.0/24 eth0 192.0.2.44 br0 - routeback eth3 - source eth4 - notrack 41 FILES /etc/shorewall/routestopped See ALSO http://shorewall.net/starting_and_stopping_shorewall.htm http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-masq.xml0000644000175000017500000006474712222401136022512 0ustar teastepteastep shorewall-masq 5 masq Shorewall Masquerade/SNAT definition file /etc/shorewall/masq Description Use this file to define dynamic NAT (Masquerading) and to define Source NAT (SNAT). The entries in this file are order-sensitive. The first entry that matches a particular connection will be the one that is used. If you have more than one ISP link, adding entries to this file will not force connections to go out through a particular link. You must use entries in shorewall-rtrules(5) or PREROUTING entries in shorewall-tcrules(5) to do that. The columns in the file are as follows. INTERFACE:DEST - {[+]interfacelist[:[digit]][:[dest-address[,dest-address]...[exclusion]]|[?]COMMENT} Outgoing interfacelist. This may be a comma-separated list of interface names. This is usually your internet interface. If ADD_SNAT_ALIASES=Yes in shorewall.conf(5), you may add ":" and a digit to indicate that you want the alias added with that name (e.g., eth0:0). This will allow the alias to be displayed with ifconfig. That is the only use for the alias name; it may not appear in any other place in your Shorewall configuration. Each interface must match an entry in shorewall-interfaces(5). Shorewall allows loose matches to wildcard entries in shorewall-interfaces(5). For example, ppp0 in this file will match a shorewall-interfaces(5) entry that defines ppp+. Where more that one internet provider share a single interface, the provider is specified by including the provider name or number in parentheses: eth0(Avvanta) In that case, you will want to specify the interface's address for that provider in the ADDRESS column. The interface may be qualified by adding the character ":" followed by a comma-separated list of destination host or subnet addresses to indicate that you only want to change the source IP address for packets being sent to those particular destinations. Exclusion is allowed (see shorewall-exclusion(5)) as are ipset names preceded by a plus sign '+'; If you wish to inhibit the action of ADD_SNAT_ALIASES for this entry then include the ":" but omit the digit: eth0(Avvanta): eth2::192.0.2.32/27 Normally Masq/SNAT rules are evaluated after those for one-to-one NAT (defined in shorewall-nat(5)). If you want the rule to be applied before one-to-one NAT rules, prefix the interface name with "+": +eth0 +eth0:192.0.2.32/27 +eth0:2 This feature should only be required if you need to insert rules in this file that preempt entries in shorewall-nat(5). Comments may be attached to Netfilter rules generated from entries in this file through the use of COMMENT lines. These lines begin with the word COMMENT; the remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word COMMENT. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. SOURCE (Formerly called SUBNET) - {interface|address[,address][exclusion]} Set of hosts that you wish to masquerade. You can specify this as an address (net or host) or as an interface (use of an interface is deprecated). If you give the name of an interface, the interface must be up before you start the firewall and the Shorewall rules compiler will warn you of that fact. (Shorewall will use your main routing table to determine the appropriate addresses to masquerade). The preferred way to specify the SOURCE is to supply one or more host or network addresses separated by comma. You may use ipset names preceded by a plus sign (+) to specify a set of hosts. ADDRESS (Optional) - [-|NONAT|[address-or-address-range[,address-or-address-range]...][:lowport-highport][:random][:persistent]|detect|random] If you specify an address here, SNAT will be used and this will be the source address. If ADD_SNAT_ALIASES is set to Yes or yes in shorewall.conf(5) then Shorewall will automatically add this address to the INTERFACE named in the first column. You may also specify a range of up to 256 IP addresses if you want the SNAT address to be assigned from that range in a round-robin fashion by connection. The range is specified by first.ip.in.range-last.ip.in.range. You may follow the port range with :random in which case assignment of ports from the list will be random. random may also be specified by itself in this column in which case random local port assignments are made for the outgoing connections. Example: 206.124.146.177-206.124.146.180 You may follow the port range (or :random) with :persistent. This is only useful when an address range is specified and causes a client to be given the same source/destination IP pair. This feature replaces the SAME modifier which was removed from Shorewall in version 4.4.0. Unlike random, persistent may not be used by itself. You may also use the special value "detect" which causes Shorewall to determine the IP addresses configured on the interface named in the INTERFACES column and substitute them in this column. Finally, you may also specify a comma-separated list of ranges and/or addresses in this column. This column may not contain DNS Names. Normally, Netfilter will attempt to retain the source port number. You may cause netfilter to remap the source port by following an address or range (if any) by ":" and a port range with the format lowport-highport. If this is done, you must specify "tcp" or "udp" in the PROTO column. Examples: 192.0.2.4:5000-6000 :4000-5000 If you simply place NONAT in this column, no rewriting of the source IP address or port number will be performed. This is useful if you want particular traffic to be exempt from the entries that follow in the file. If you want to leave this column empty but you need to specify the next column then place a hyphen ("-") here. PROTO (Optional) - {-|[!]{protocol-name|protocol-number}[,...]} If you wish to restrict this entry to a particular protocol then enter the protocol name (from protocols(5)) or number here. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. PORT(S) (Optional) - [[!]port-name-or-number[,port-name-or-number]...] If the PROTO column specifies TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136) then you may list one or more port numbers (or names from services(5)) or port ranges separated by commas. Port ranges are of the form lowport:highport. IPSEC (Optional) - [option[,option]...] If you specify a value other than "-" in this column, you must be running kernel 2.6 and your kernel and iptables must include policy match support. Comma-separated list of options from the following. Only packets that will be encrypted via an SA that matches these options will have their source address changed. reqid=number where number is specified using setkey(8) using the 'unique:number option for the SPD level. spi=<number> where number is the SPI of the SA used to encrypt/decrypt packets. proto=ah|esp|ipcomp IPSEC Encapsulation Protocol mss=number sets the MSS field in TCP packets mode=transport|tunnel IPSEC mode tunnel-src=address[/mask] only available with mode=tunnel tunnel-dst=address[/mask] only available with mode=tunnel strict Means that packets must match all rules. next Separates rules; can only be used with strict yes When used by itself, causes all traffic that will be encrypted/encapsulated to match the rule. MARK - [!]value[/mask][:C] Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. USER/GROUP (Optional) - [!][user-name-or-number][:group-name-or-number][+program-name] Only locally-generated connections will match if this column is non-empty. When this column is non-empty, the rule matches only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given). Examples: joe program must be run by joe :kids program must be run by a member of the 'kids' group !:kids program must not be run by a member of the 'kids' group +upnpd #program named upnpd The ability to specify a program name was removed from Netfilter in kernel version 2.6.14. SWITCH - [!]switch-name[={0|1}] Added in Shorewall 4.5.1 and allows enabling and disabling the rule without requiring shorewall restart. The rule is enabled if the value stored in /proc/net/nf_condition/switch-name is 1. The rule is disabled if that file contains 0 (the default). If '!' is supplied, the test is inverted such that the rule is enabled if the file contains 0. Within the switch-name, '@0' and '@{0}' are replaced by the name of the chain to which the rule is a added. The switch-name (after '@...' expansion) must begin with a letter and be composed of letters, decimal digits, underscores or hyphens. Switch names must be 30 characters or less in length. Switches are normally off. To turn a switch on: echo 1 > /proc/net/nf_condition/switch-name To turn it off again: echo 0 > /proc/net/nf_condition/switch-name Switch settings are retained over shorewall restart. Beginning with Shorewall 4.5.10, when the switch-name is followed by or , then the switch is initialized to off or on respectively by the start command. Other commands do not affect the switch setting. ORIGINAL DEST (origdest) - [-|address[,address]...[exclusion]|exclusion] (Optional) Added in Shorewall 4.5.6. This column may be included and may contain one or more addresses (host or network) separated by commas. Address ranges are not allowed. When this column is supplied, rules are generated that require that the original destination address matches one of the listed addresses. It is useful for specifying that SNAT should occur only for connections that were acted on by a DNAT when they entered the firewall. Examples Example 1: You have a simple masquerading setup where eth0 connects to a DSL or cable modem and eth1 connects to your local network with subnet 192.168.0.0/24. Your entry in the file will be: #INTERFACE SOURCE eth0 192.168.0.0/24 Example 2: You add a router to your local network to connect subnet 192.168.1.0/24 which you also want to masquerade. You then add a second entry for eth0 to this file: #INTERFACE SOURCE eth0 192.168.1.0/24 Example 3: You have an IPSEC tunnel through ipsec0 and you want to masquerade packets coming from 192.168.1.0/24 but only if these packets are destined for hosts in 10.1.1.0/24: #INTERFACE SOURCE ipsec0:10.1.1.0/24 196.168.1.0/24 Example 4: You want all outgoing traffic from 192.168.1.0/24 through eth0 to use source address 206.124.146.176 which is NOT the primary address of eth0. You want 206.124.146.176 to be added to eth0 with name eth0:0. #INTERFACE SOURCE ADDRESS eth0:0 192.168.1.0/24 206.124.146.176 Example 5: You want all outgoing SMTP traffic entering the firewall from 172.20.1.0/29 to be sent from eth0 with source IP address 206.124.146.177. You want all other outgoing traffic from 172.20.1.0/29 to be sent from eth0 with source IP address 206.124.146.176. #INTERFACE SOURCE ADDRESS PROTO PORT(S) eth0 172.20.1.0/29 206.124.146.177 tcp smtp eth0 172.20.1.0/29 206.124.146.176 The order of the above two rules is significant! Example 6: Connections leaving on eth0 and destined to any host defined in the ipset myset should have the source IP address changed to 206.124.146.177. #INTERFACE SOURCE ADDRESS eth0:+myset[dst] - 206.124.146.177 Example 7: SNAT outgoing connections on eth0 from 192.168.1.0/24 in round-robin fashion between addresses 1.1.1.1, 1.1.1.3, and 1.1.1.9 (Shorewall 4.5.9 and later). /etc/shorewall/tcrules: #ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST # PORT(S) 1-3:CF 192.168.1.0/24 eth0 ; state=NEW /etc/shorewall/masq: #INTERFACE SOURCE ADDRESS ... eth0 192.168.1.0/24 1.1.1.1 ; mark=1:C eth0 192.168.1.0/24 1.1.1.3 ; mark=2:C eth0 192.168.1.0/24 1.1.1.4 ; mark=3:C FILES /etc/shorewall/masq See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-exclusion(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-nesting.xml0000644000175000017500000002206412222401136023202 0ustar teastepteastep shorewall-nesting 5 nesting Shorewall Nested Zones child-zone[:parent-zone[,parent-zone]...] Description In shorewall-zones(5), a zone may be declared to be a sub-zone of one or more other zones using the above syntax. The child-zone may be neither the firewall zone nor a vserver zone. The firewall zone may not appear as a parent zone, although all vserver zones are handled as sub-zones of the firewall zone. Where zones are nested, the CONTINUE policy in shorewall-policy(5) allows hosts that are within multiple zones to be managed under the rules of all of these zones. Example /etc/shorewall/zones: #ZONE TYPE OPTION fw firewall net ipv4 sam:net ipv4 loc ipv4 /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS - eth0 detect dhcp,norfc1918 loc eth1 detect /etc/shorewall/hosts: #ZONE HOST(S) OPTIONS net eth0:0.0.0.0/0 sam eth0:206.191.149.197 /etc/shorewall/policy: #SOURCE DEST POLICY LOG LEVEL loc net ACCEPT sam all CONTINUE net all DROP info all all REJECT info The second entry above says that when Sam is the client, connection requests should first be processed under rules where the source zone is sam and if there is no match then the connection request should be treated under rules where the source zone is net. It is important that this policy be listed BEFORE the next policy (net to all). You can have this policy generated for you automatically by using the IMPLICIT_CONTINUE option in shorewall.conf(5). Partial /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) ... DNAT sam loc:192.168.1.3 tcp ssh DNAT net loc:192.168.1.5 tcp www ... Given these two rules, Sam can connect to the firewall's internet interface with ssh and the connection request will be forwarded to 192.168.1.3. Like all hosts in the net zone, Sam can connect to the firewall's internet interface on TCP port 80 and the connection request will be forwarded to 192.168.1.5. The order of the rules is not significant. Sometimes it is necessary to suppress port forwarding for a sub-zone. For example, suppose that all hosts can SSH to the firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects to the firewall's external IP, he should be connected to the firewall itself. Because of the way that Netfilter is constructed, this requires two rules as follows: #ACTION SOURCE DEST PROTO DEST PORT(S) ... ACCEPT+ sam $FW tcp ssh DNAT net loc:192.168.1.3 tcp ssh ... The first rule allows Sam SSH access to the firewall. The second rule says that any clients from the net zone with the exception of those in the “sam” zone should have their connection port forwarded to 192.168.1.3. If you need to exclude more than one zone, simply use multiple ACCEPT+ rules. This technique also may be used when the ACTION is REDIRECT. Care must be taken when nesting occurs as a result of the use of wildcard interfaces (interface names ends in '+'). Here's an example. /etc/shorewall/zones: /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net ppp0 loc eth1 loc ppp+ dmz eth2 Because the net zone is declared before the loc zone, net is an implicit sub-zone of loc and in the absence of a net->... CONTINUE policy, traffic from the net zone will not be passed through loc->... rules. But DNAT and REDIRECT rules are an exception! DNAT and REDIRECT rules generate two Netfilter rules: a 'nat' table rule that rewrites the destination IP address and/or port number, and a 'filter' table rule that ACCEPTs the rewritten connection. Policies only affect the 'filter' table. As a consequence, the following rules will have unexpected behavior: #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT net dmz tcp 80 REDIRECT loc 3128 tcp 80 The second rule is intended to redirect local web requests to a proxy running on the firewall and listening on TCP port 3128. But the 'nat' part of that rule will cause all connection requests for TCP port 80 arriving on interface ppp+ (including ppp0!) to have their destination port rewritten to 3128. Hence, the web server running in the DMZ will be inaccessible from the web. The above problem can be corrected in several ways. The preferred way is to use the pppd option to change the 'net' interface to something other than ppp0. That way, it won't match ppp+. If you are running Shorewall version 4.1.4 or later, a second way is to simply make the nested zones explicit: #ZONE TYPE OPTION fw firewall loc ipv4 net:loc ipv4 dmz ipv4 If you take this approach, be sure to set IMPLICIT_CONTINUE=No in shorewall.conf. When using other Shorewall versions, another way is to rewrite the DNAT rule (assume that the local zone is entirely within 192.168.2.0/23): #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT net dmz tcp 80 REDIRECT loc:192.168.2.0/23 3128 tcp 80 Another way is to restrict the definition of the loc zone: /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net ppp0 loc eth1 - ppp+ dmz eth2 /etc/shorewall/hosts: #ZONE HOST(S) OPTIONS loc ppp+:192.168.2.0/23 FILES /etc/shorewall/zones /etc/shorewall/interfaces /etc/shorewall/hosts /etc/shorewall/policy /etc/shorewall/rules See ALSO shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-interfaces.xml0000644000175000017500000011125612222401136023660 0ustar teastepteastep shorewall-interfaces 5 interfaces Shorewall interfaces file /etc/shorewall/interfaces Description The interfaces file serves to define the firewall's network interfaces to Shorewall. The order of entries in this file is not significant in determining zone composition. Beginning with Shorewall 4.5.3, the interfaces file supports two different formats: FORMAT 1 (default - deprecated) There is a BROADCAST column which can be used to specify the broadcast address associated with the interface. FORMAT 2 The BROADCAST column is omitted. The format is specified by a line as follows:
[?]FORMAT {1|2}
The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is the preferred form; the form without the '?' is deprecated. The columns in the file are as follows. ZONE - zone-name Zone for this interface. Must match the name of a zone declared in /etc/shorewall/zones. You may not list the firewall zone in this column. If the interface serves multiple zones that will be defined in the shorewall-hosts(5) file, you should place "-" in this column. If there are multiple interfaces to the same zone, you must list them in separate entries. Example:
#ZONE INTERFACE BROADCAST loc eth1 - loc eth2 -
INTERFACE - interface[:port] Logical name of interface. Each interface may be listed only once in this file. You may NOT specify the name of a "virtual" interface (e.g., eth0:0) here; see http://www.shorewall.net/FAQ.htm#faq18. If the option is not specified, then the logical name is also the name of the actual interface. You may use wildcards here by specifying a prefix followed by the plus sign ("+"). For example, if you want to make an entry that applies to all PPP interfaces, use 'ppp+'; that would match ppp0, ppp1, ppp2, … Please note that the '+' means 'one or more additional characters' so 'ppp' does not match 'ppp+'. When using Shorewall versions before 4.1.4, care must be exercised when using wildcards where there is another zone that uses a matching specific interface. See shorewall-nesting(5) for a discussion of this problem. Shorewall allows '+' as an interface name. There is no need to define the loopback interface (lo) in this file. If a port is given, then the interface must have been defined previously with the option. The OPTIONS column may not contain the following options when a port is given. arp_filter arp_ignore bridge log_martians mss optional proxyarp required routefilter sourceroute upnp wait Beginning with Shorewall 4.5.17, if you specify a zone for the 'lo' interface, then that zone must be defined as type in shorewall6-zones(5). BROADCAST (Optional) - {-|detect|address[,address]...} Only available if FORMAT 1. If you use the special value detect, Shorewall will detect the broadcast address(es) for you if your iptables and kernel include Address Type Match support. If your iptables and/or kernel lack Address Type Match support then you may list the broadcast address(es) for the network(s) to which the interface belongs. For P-T-P interfaces, this column is left blank. If the interface has multiple addresses on multiple subnets then list the broadcast addresses as a comma-separated list. If you don't want to give a value for this column but you want to enter a value in the OPTIONS column, enter - in this column. OPTIONS (Optional) - [option[,option]...] A comma-separated list of options from the following list. The order in which you list the options is not significant but the list should have no embedded white-space. arp_filter[={0|1}] If specified, this interface will only respond to ARP who-has requests for IP addresses configured on the interface. If not specified, the interface can respond to ARP who-has requests for IP addresses on any of the firewall's interface. The interface must be up when Shorewall is started. Only those interfaces with the option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given. This option does not work with a wild-card interface name (e.g., eth0.+) in the INTERFACE column. arp_ignore[=number] If specified, this interface will respond to arp requests based on the value of number (defaults to 1). 1 - reply only if the target IP address is local address configured on the incoming interface 2 - reply only if the target IP address is local address configured on the incoming interface and the sender's IP address is part from same subnet on this interface's address 3 - do not reply for local addresses configured with scope host, only resolutions for global and link 4-7 - reserved 8 - do not reply for all local addresses This option does not work with a wild-card interface name (e.g., eth0.+) in the INTERFACE column. Do not specify arp_ignore for any interface involved in Proxy ARP. blacklist Checks packets arriving on this interface against the shorewall-blacklist(5) file. Beginning with Shorewall 4.4.13: If a zone is given in the ZONES column, then the behavior is as if blacklist had been specified in the IN_OPTIONS column of shorewall-zones(5). Otherwise, the option is ignored with a warning:
WARNING: The 'blacklist' option is ignored on multi-zone interfaces
bridge Designates the interface as a bridge. Beginning with Shorewall 4.4.7, setting this option also sets . destonly Added in Shorewall 4.5.17. Causes the compiler to omit rules to handle traffic from this interface. dhcp Specify this option when any of the following are true: the interface gets its IP address via DHCP the interface is used by a DHCP server running on the firewall the interface has a static IP but is on a LAN segment with lots of DHCP clients. the interface is a simple bridge with a DHCP server on one port and DHCP clients on another port. If you use Shorewall-perl for firewall/bridging, then you need to include DHCP-specific rules in shorewall-rules(8). DHCP uses UDP ports 67 and 68. This option allows DHCP datagrams to enter and leave the interface. ignore[=1] When specified, causes the generated script to ignore up/down events from Shorewall-init for this device. Additionally, the option exempts the interface from hairpin filtering. When '=1' is omitted, the ZONE column must contain '-' and must be the only OPTION. Beginning with Shorewall 4.5.5, may be specified as '' which only causes the generated script to ignore up/down events from Shorewall-init; hairpin filtering is still applied. In this case, the above restrictions on the ZONE and OPTIONS columns are lifted. logmartians[={0|1}] Turn on kernel martian logging (logging of packets with impossible source addresses. It is strongly suggested that if you set routefilter on an interface that you also set logmartians. Even if you do not specify the option, it is a good idea to specify because your distribution may have enabled route filtering without you knowing it. Only those interfaces with the option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given. To find out if route filtering is set on a given interface, check the contents of /proc/sys/net/ipv4/conf/interface/rp_filter - a non-zero value indicates that route filtering is enabled. Example: teastep@lists:~$ cat /proc/sys/net/ipv4/conf/eth0/rp_filter 1 teastep@lists:~$ This option does not work with a wild-card interface name (e.g., eth0.+) in the INTERFACE column.
This option may also be enabled globally in the shorewall.conf(5) file.
maclist Connection requests from this interface are compared against the contents of shorewall-maclist(5). If this option is specified, the interface must be an Ethernet NIC and must be up before Shorewall is started. mss=number Added in Shorewall 4.0.3. Causes forwarded TCP SYN packets entering or leaving on this interface to have their MSS field set to the specified number. nets=(net[,...]) Limit the zone named in the ZONE column to only the listed networks. The parentheses may be omitted if only a single net is given (e.g., nets=192.168.1.0/24). Limited broadcast to the zone is supported. Beginning with Shorewall 4.4.1, multicast traffic to the zone is also supported. nets=dynamic Defines the zone as dynamic. Requires ipset match support in your iptables and kernel. See http://www.shorewall.net/Dynamic.html for further information. nosmurfs Filter packets for smurfs (packets with a broadcast address as the source). Smurfs will be optionally logged based on the setting of SMURF_LOG_LEVEL in shorewall.conf(5). After logging, the packets are dropped. optional When is specified for an interface, Shorewall will be silent when: a /proc/sys/net/ipv4/conf/ entry for the interface cannot be modified (including for proxy ARP). The first address of the interface cannot be obtained. May not be specified with required. physical=name Added in Shorewall 4.4.4. When specified, the interface or port name in the INTERFACE column is a logical name that refers to the name given in this option. It is useful when you want to specify the same wildcard port name on two or more bridges. See http://www.shorewall.net/bridge-Shorewall-perl.html#Multiple. If the interface name is a wildcard name (ends with '+'), then the physical name must also end in '+'. If is not specified, then it's value defaults to the interface name. proxyarp[={0|1}] Sets /proc/sys/net/ipv4/conf/interface/proxy_arp. Do NOT use this option if you are employing Proxy ARP through entries in shorewall-proxyarp(5). This option is intended solely for use with Proxy ARP sub-networking as described at: http://tldp.org/HOWTO/Proxy-ARP-Subnet/index.html. Note: This option does not work with a wild-card interface name (e.g., eth0.+) in the INTERFACE column. Only those interfaces with the option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given. required Added in Shorewall 4.4.10. If this option is set, the firewall will fail to start if the interface is not usable. May not be specified together with optional. routeback[={0|1}] If specified, indicates that Shorewall should include rules that allow traffic arriving on this interface to be routed back out that same interface. This option is also required when you have used a wildcard in the INTERFACE column if you want to allow traffic between the interfaces that match the wildcard. Beginning with Shorewall 4.4.20, if you specify this option, then you should also specify either (see below) or on all interfaces (see below). Beginning with Shorewall 4.5.18, you may specify this option to explicitly reset (e.g., routeback=0). This can be used to override Shorewall's default setting for bridge devices which is routeback=1. routefilter[={0|1|2}] Turn on kernel route filtering for this interface (anti-spoofing measure). Only those interfaces with the option will have their setting changes; the value assigned to the setting will be the value specified (if any) or 1 if no value is given. The value 2 is only available with Shorewall 4.4.5.1 and later when the kernel version is 2.6.31 or later. It specifies a loose form of reverse path filtering. This option does not work with a wild-card interface name (e.g., eth0.+) in the INTERFACE column. This option can also be enabled globally via the ROUTE_FILTER option in the shorewall.conf(5) file. If ROUTE_FILTER=Yes in shorewall.conf(5), or if your distribution sets net.ipv4.conf.all.rp_filter=1 in /etc/sysctl.conf, then setting routefilter=0 in an interface entry will not disable route filtering on that interface! The effective setting for an interface is the maximum of the contents of /proc/sys/net/ipv4/conf/all/rp_filter and the routefilter setting specified in this file (/proc/sys/net/ipv4/conf/interface/rp_filter). There are certain cases where cannot be used on an interface: If USE_DEFAULT_RT=Yes in shorewall.conf(5) and the interface is listed in shorewall-providers(5). If there is an entry for the interface in shorewall-providers(5) that doesn't specify the option. If IPSEC is used to allow a road-warrior to have a local address, then any interface through which the road-warrior might connect cannot specify . rpfilter Added in Shorewall 4.5.7. This is an anti-spoofing measure that requires the 'RPFilter Match' capability in your iptables and kernel. It provides a more efficient alternative to the option below. It performs a function similar to (see above) but works with Multi-ISP configurations that do now use balanced routes. sfilter=(net[,...]) Added in Shorewall 4.4.20. This option provides an anti-spoofing alternative to on interfaces where that option cannot be used, but where the option is required (on a bridge, for example). On these interfaces, should list those local networks that are connected to the firewall through other interfaces. sourceroute[={0|1}] If this option is not specified for an interface, then source-routed packets will not be accepted from that interface unless it has been explicitly enabled via sysconf. Only set this option to 1 (enable source routing) if you know what you are doing. This might represent a security risk and is usually unneeded. Only those interfaces with the option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given. This option does not work with a wild-card interface name (e.g., eth0.+) in the INTERFACE column. tcpflags Packets arriving on this interface are checked for certain illegal combinations of TCP flags. Packets found to have such a combination of flags are handled according to the setting of TCP_FLAGS_DISPOSITION after having been logged according to the setting of TCP_FLAGS_LOG_LEVEL. unmanaged Added in Shorewall 4.5.18. Causes all traffic between the firewall and hosts on the interface to be accepted. When this option is given: The ZONE column must contain '-'. Only the following other options are allowed with unmanaged: arp_filter arp_ignore ignore routefilter optional physical routefilter sourceroute proxyndp upnp Incoming requests from this interface may be remapped via UPNP (upnpd). See http://www.shorewall.net/UPnP.html. upnpclient This option is intended for laptop users who always run Shorewall on their system yet need to run UPnP-enabled client apps such as Transmission (BitTorrent client). The option causes Shorewall to detect the default gateway through the interface and to accept UDP packets from that gateway. Note that, like all aspects of UPnP, this is a security hole so use this option at your own risk. wait=seconds Added in Shorewall 4.4.10. Causes the generated script to wait up to seconds seconds for the interface to become usable before applying the required or optional options.
Example Example 1: Suppose you have eth0 connected to a DSL modem and eth1 connected to your local network and that your local subnet is 192.168.1.0/24. The interface gets its IP address via DHCP from subnet 206.191.149.192/27. You have a DMZ with subnet 192.168.2.0/24 using eth2. Your iptables and/or kernel do not support "Address Type Match" and you prefer to specify broadcast addresses explicitly rather than having Shorewall detect them. Your entries for this setup would look like: FORMAT 1 #ZONE INTERFACE BROADCAST OPTIONS net eth0 206.191.149.223 dhcp loc eth1 192.168.1.255 dmz eth2 192.168.2.255 Example 2: The same configuration without specifying broadcast addresses is: FORMAT 2 #ZONE INTERFACE OPTIONS net eth0 dhcp loc eth1 dmz eth2 Example 3: You have a simple dial-in system with no Ethernet connections. FORMAT 2 #ZONE INTERFACE OPTIONS net ppp0 - Example 4 (Shorewall 4.4.9 and later): You have a bridge with no IP address and you want to allow traffic through the bridge. FORMAT 2 #ZONE INTERFACE OPTIONS - br0 routeback FILES /etc/shorewall/interfaces See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall.conf.xml0000644000175000017500000035740312222401136022471 0ustar teastepteastep shorewall.conf 5 shorewall.conf Shorewall global configuration file /etc/shorewall/shorewall.conf Description This file sets options that apply to Shorewall as a whole. The file consists of Shell comments (lines beginning with '#'), blank lines and assignment statements (variable=value). If the value contains shell meta characters or white-space, then it must be enclosed in quotes. Example: MACLIST_LOG_LEVEL="NFLOG(1,0,1)". OPTIONS Many options have as their value a log-level. Log levels are a method of describing to syslog (8) the importance of a message and a number of parameters in this file have log levels as their value. These levels are defined by syslog and are used to determine the destination of the messages through entries in /etc/syslog.conf (5). The syslog documentation refers to these as "priorities"; Netfilter calls them "levels" and Shorewall also uses that term. Valid levels are: 7 debug 6 info 5 notice 4 warning 3 err 2 crit 1 alert 0 emerg For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall log messages are generated by NetFilter and are logged using facility 'kern' 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. If you have built your kernel with ULOG and/or NFLOG target support, you may also specify a log level of ULOG and/or NFLOG (must be all caps). Rather than log its messages to syslogd, Shorewall will direct netfilter to log the messages via the ULOG or NFLOG target which will send them to a process called 'ulogd'. ulogd is available with most Linux distributions (although it probably isn't installed by default). Ulogd is also available from http://www.netfilter.org/projects/ulogd/index.html and can be configured to log all Shorewall messages to their own log file. Beginning with Shorewall 4.4.22, LOGMARK is also a valid level which logs the packet's mark value along with the other usual information. The syntax is: LOGMARK[(priority)] where priority is one of the levels listed in the list above. If omitted, the default is info (6). The following options may be set in shorewall.conf. ACCEPT_DEFAULT={action[(parameters)][:level]|none} DROP_DEFAULT={action[(parameters)][:level]|none} NFQUEUE_DEFAULT={action[(parameters)][:level]|none} QUEUE_DEFAULT={action[(parameters)][:level]|none} REJECT_DEFAULT={action[(parameters)][:level]|none} In earlier Shorewall versions, a "default action" for DROP and REJECT policies was specified in the file /usr/share/shorewall/actions.std. In Shorewall 4.4.0, the DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT, QUEUE_DEFAULT and NFQUEUE_DEFAULT options were added. 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 three are similar for ACCEPT, QUEUE and NFQUEUE policies. The value applied to these may be: The default values are: DROP_DEFAULT="Drop" REJECT_DEFAULT="Reject" ACCEPT_DEFAULT="none" QUEUE_DEFAULT="none" NFQUEUE_DEFAULT="None" If you set the value of either option to "None" then no default action will be used and the default action or macro must be specified in shorewall-policy(5). You can pass parameters to the specified action (e.g., myaction(audit,DROP)). Beginning with Shorewall 4.5.10, the action name can be followed optionally by a colon and a log level. The level will be applied to each rule in the action or body that does not already have a log level. ACCOUNTING=[Yes|No] Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting is enabled (see shorewall-accounting(5)). If not specified or set to the empty value, ACCOUNTING=Yes is assumed. ACCOUNTING_TABLE=[filter|mangle] Added in Shorewall 4.4.20. This setting determines which Netfilter table the accounting rules are added in. By default, ACCOUNTING_TABLE=filter is assumed. See also shorewall-accounting(5). ADD_IP_ALIASES=[Yes|No] This parameter determines whether Shorewall automatically adds the external address(es) in shorewall-nat(5). If the variable is set to Yes or yes then Shorewall automatically adds these aliases. If it is set to No or no, you must add these aliases yourself using your distribution's network configuration tools. If this variable is not set or is given an empty value (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed. 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. ADD_SNAT_ALIASES=[Yes|No] This parameter determines whether Shorewall automatically adds the SNAT ADDRESS in shorewall-masq(5). If the variable is set to Yes or yes then Shorewall automatically adds these addresses. If it is set to No or no, you must add these addresses yourself using your distribution's network configuration tools. If this variable is not set or is given an empty value (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed. 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. ADMINISABSENTMINDED=[Yes|No] The value of this variable affects Shorewall's stopped state. When ADMINISABSENTMINDED=No, only traffic to/from those addresses listed in shorewall-routestopped(5) is accepted when Shorewall is stopped. When ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in shorewall-routestopped(5), connections that were active when Shorewall stopped continue to work and all new connections from the firewall system itself are allowed. If this variable is not set or is given the empty value then ADMINISABSENTMINDED=No is assumed. ARPTABLES=[pathname] Added in Shorewall 4.5.12. This parameter names the arptables executable to be used by Shorewall. If not specified or if specified as a null value, then the arptables executable located using the PATH option is used. Regardless of how the arptables utility is located (specified via arptables= or located via PATH), Shorewall uses the arptables-restore and arptables-save utilities from that same directory. AUTOCOMMENT=[Yes|No] Formerly named AUTO_COMMENT. If set, if there is not a current comment when a macro is invoked, the behavior is as if the first line of the macro file was "COMMENT <macro name>". The AUTO_COMMENT option has a default value of 'Yes'. The setting of the AUTOMAKE option is ignored if the start or restart command includes a directory name (e.g., shorewall restart /etc/shorewall.new). AUTOHELPERS=[Yes|No] Added in Shorewall 4.5.7. When set to (the default), the generated ruleset will automatically associate helpers with applications that require them (FTP, IRC, etc.). When configuring your firewall on systems running kernel 3.5 or later, it is recommended that you: Set AUTOHELPERS=No. Either: Modify shorewall-conntrack (5) to only apply helpers where they are required; or Specify the appropriate helper in the HELPER column in shorewall-rules (5). The macros for those applications requiring a helper automatically specify the appropriate HELPER where required. AUTOMAKE=[Yes|No] If set, the behavior of the 'start' command is changed; if no files in /etc/shorewall have been changed since the last successful start or restart command, then the compilation step is skipped and the compiled script that executed the last start or restart command is used. The default is AUTOMAKE=No. BLACKLIST=[{ALL|state[,...]}] where state is one of NEW, ESTABLISHED, RELATED, INVALID,or UNTRACKED. Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option below. Specifies the connection tracking states that are to be subject to blacklist screening. If neither BLACKLIST nor BLACKLISTNEWONLY are specified then the states subject to blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED. ALL sends all packets through the blacklist chains. Note: The ESTABLISHED state may not be specified if FASTACCEPT is specified. BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT] This parameter determines the disposition of packets from blacklisted hosts. It may have the value DROP if the packets are to be dropped or REJECT if the packets are to be replied with an ICMP port unreachable reply or a TCP RST (tcp only). If you do not assign a value or if you assign an empty value then DROP is assumed. A_DROP and A_REJECT are audited versions of DROP and REJECT respectively and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel and iptables. The BLACKLIST_DISPOSITION setting has no effect on entries in the BLACKLIST section of shorewall-rules (5). It determines the disposition of packets sent to the blacklog target of shorewall-blrules (5). BLACKLIST_LOG_LEVEL=[log-level] Formerly named BLACKLIST_LOGLEVEL. This parameter determines if packets from blacklisted hosts are logged and it determines the syslog level that they are to be logged at. Its value is a syslog level (Example: BLACKLIST_LOG_LEVEL=debug). If you do not assign a value or if you assign an empty value then packets from blacklisted hosts are not logged. The setting determines the log level of packets sent to the blacklog target of shorewall-blrules(5). BLACKLISTNEWONLY={Yes|No} Deprecated in Shorewall 4.5.13 in favor of BLACKLIST above. When set to Yes or yes, blacklists are only consulted for new connections and for packets in the INVALID connection state (such as TCP SYN,ACK when there has been no corresponding SYN). That includes entries in the shorewall-blrules (5) file and in the BLACKLIST section of shorewall-rules (5). When set to No or no, blacklists are consulted for every packet (will slow down your firewall noticeably if you have large blacklists). If the BLACKLISTNEWONLY option is not set or is set to the empty value then BLACKLISTNEWONLY=No is assumed. BLACKLISTNEWONLY=No is incompatible with FASTACCEPT=Yes. CHAIN_SCRIPTS={Yes|No} Added in Shorewall 4.5.16. Prior to the availability of BEGIN PERL....END PERL in configuration files, the only way to execute a chain-specific script was to create a script file with the same name as the chain and place it in a directory on the CONFIG_PATH. That facility has the drawback that the compiler will attempt to run a non-script file just because it has the same name as a chain. To disable this facility, set CHAIN_SCRIPTS=No. If not specified or specified as the empty value, CHAIN_SCRIPTS=Yes is assumed. CLAMPMSS=[Yes|No|value] This parameter enables the TCP Clamp MSS to PMTU feature of Netfilter and is usually required when your internet connection is through PPPoE or PPTP. If set to Yes or yes, the feature is enabled. If left blank or set to No or no, the feature is not enabled. Important: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel. You may also set CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400). This will set the MSS field in TCP SYN packets going through the firewall to the value that you specify. CLEAR_TC=[Yes|No] If this option is set to No then Shorewall won't clear the current traffic control rules during [re]start. This setting is intended for use by people who prefer to configure traffic shaping when the network interfaces come up rather than when the firewall is started. If that is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That way, your traffic shaping rules can still use the “fwmark” classifier based on packet marking defined in shorewall-tcrules(5). If not specified, CLEAR_TC=Yes is assumed. COMPLETE=[Yes|No] Added in Shorewall 4.4.12. When you set this option to Yes, you are asserting that the configuration is complete so that your set of zones encompasses any hosts that can send or receive traffic to/from/through the firewall. This causes Shorewall to omit the rules that catch packets in which the source or destination IP address is outside of any of your zones. Default is No. It is recommended that this option only be set to Yes if: You have defined an interface whose effective physical setting is '+'. That interface is assigned to a zone. You have no CONTINUE policies or rules. CONFIG_PATH=[directory[:directory]...] Specifies where configuration files other than shorewall.conf may be found. CONFIG_PATH is specifies as a list of directory names separated by colons (":"). When looking for a configuration file other than shorewall.conf: If the command is "try" or a "<configuration directory>" was specified in the command (e.g., shorewall check ./gateway) then the directory given in the command is searched first. Next, each directory in the CONFIG_PATH setting is searched in sequence. If CONFIG_PATH is not given or if it is set to the empty value then the contents of /usr/share/shorewall/configpath are used. As released from shorewall.net, that file sets the CONFIG_PATH to /etc/shorewall:/usr/share/shorewall but your particular distribution may set it differently. See the output of shorewall show config for the default on your system. DEFER_DNS_RESOLUTION=[Yes|No] Added in Shorewall 4.5.12. When set to 'Yes' (the default), DNS names are validated in the compiler and then passed on to the generated script where they are resolved by iptables-restore. This is an advantage if you use AUTOMAKE=Yes and the IP address associated with the DNS name is subject to change. When DEFER_DNS_RESOLUTION=No, DNS names are converted into IP addresses by the compiler. This has the advantage that when AUTOMAKE=Yes, the start and restart commands will succeed even if no DNS server is reachable (assuming that the configuration hasn't changed since the compiled script was last generated). DELETE_THEN_ADD={Yes|No} If set to Yes (the default value), entries in the /etc/shorewall/route_stopped files cause an 'ip rule del' command to be generated in addition to an 'ip rule add' command. Setting this option to No, causes the 'ip rule del' command to be omitted. DETECT_DNAT_IPADDRS=[Yes|No] If set to Yes or yes, Shorewall will detect the first IP address of the interface to the source zone and will include this address in DNAT rules as the original destination IP address. If set to No or no, Shorewall will not detect this address and any destination IP address will match the DNAT rule. If not specified or empty, “DETECT_DNAT_IPADDRS=Yes” is assumed. DISABLE_IPV6=[Yes|No] If set to Yes or yes, IPv6 traffic to, from and through the firewall system is disabled. If set to No or no, Shorewall will take no action with respect to allowing or disallowing IPv6 traffic. If not specified or empty, “DISABLE_IPV6=No” is assumed. It is important to note that changing DISABLE_IPV6=Yes to DISABLE_IPV6=No does not enable IPV6. The recommended approach for enabling IPv6 on your system is: Install, configure and start Shorewall6. Change DISABLE_IPV6=Yes to DISABLE_IPV6=No Restart Shorewall DONT_LOAD=[module[,module]...] Causes Shorewall to not load the listed kernel modules. DYNAMIC_BLACKLIST={Yes|No} Added in Shorewall 4.4.7. When set to No or no, dynamic blacklisting using the shorewall drop, shorewall reject, shorewall logdrop and shorewall logreject is disabled. Default is Yes. EXPAND_POLICIES={Yes|No} Normally, when the SOURCE or DEST columns in shorewall-policy(5) contains 'all', a single policy chain is created and the policy is enforced in that chain. For example, if the policy entry is#SOURCE DEST POLICY LOG # LEVEL net all DROP infothen the chain name is 'net2all' which is also the chain named in Shorewall log messages generated as a result of the policy. If EXPAND_POLICIES=Yes, then Shorewall will create a separate chain for each pair of zones covered by the policy. This makes the resulting log messages easier to interpret since the chain in the messages will have a name of the form 'a2b' where 'a' is the SOURCE zone and 'b' is the DEST zone. EXPORTMODULES=[Yes|No] Added in Shorewall 4.4.17. When set to Yes when compiling for use by Shorewall Lite (shorewall load, shorewall reload or shorewall export commands), the compiler will copy the modules or helpers file from the administrative system into the script. When set to No or not specified, the compiler will not copy the modules or helpers file from /usr/share/shorewall but will copy the found in another location on the CONFIG_PATH. When compiling for direct use by Shorewall, causes the contents of the local module or helpers file to be copied into the compiled script. When set to No or not set, the compiled script reads the file itself. EXPORTPARAMS={Yes|No} Deprecated in Shorewall 4.4.17. Beginning with Shorewall 4.4.17, the variables set in the 'params' file at compile time are available at run time with EXPORTPARAMS=No. As a consequence, beginning with that version the recommended setting is EXPORTPARAMS=No. It is quite difficult to code a 'params' file that assigns other than constant values such that it works correctly with Shorewall Lite. The EXPORTPARAMS option works around this problem. When EXPORTPARAMS=No, the 'params' file is not copied to the compiler output. With EXPORTPARAMS=No, if you need to set environmental variables on the firewall system for use by your extension scripts, then do so in the init extension script. The default is EXPORTPARAMS=Yes which is the recommended setting unless you are using Shorewall Lite. FASTACCEPT={Yes|No} Normally, Shorewall defers accepting ESTABLISHED/RELATED packets until these packets reach the chain in which the original connection was accepted. So for packets going from the 'loc' zone to the 'net' zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net' chain. If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED packets are accepted early in the INPUT, FORWARD and OUTPUT chains. If you set FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or RELATED sections of shorewall-rules(5). FASTACCEPT=Yes is incompatible with BLACKLISTNEWONLY=No. FORWARD_CLEAR_MARK={Yes|No} Added in Shorewall 4.4.11 Beta 3. Traditionally, Shorewall has cleared the packet mark in the first rule in the mangle FORWARD chain. This behavior is maintained with the default setting of this option (FORWARD_CLEAR_MARK=Yes). If FORWARD_CLEAR_MARK is set to 'No', packet marks set in the mangle PREROUTING chain are retained in the FORWARD chains. GEOIPDIR=[pathname] Added in Shorewall 4.5.4. Specifies the pathname of the directory containing the GeoIP Match database. See http://www.shorewall.net/ISO-3661.html. If not specified, the default value is /usr/share/xt_geoip/LE which is the default location of the little-endian database. HELPERS=[helper[,helper...]] Added in Shorewall 4.5.7. This option lists the Netfilter application helps that are to be enabled. If not specified, the default is to enable all helpers. Possible values for helper are: amanda ftp h323 irc netbios-ns none - This special value was added in Shorewall 4.5.16 and indicates that no helpers are to be enabled. It also prevents the compiler for probing for helper support; such probing generates messages on the system log of the form "xt_CT: No such helper XXX" where XXX is the helper name. When used, none must be the only helper specified. pptp sane sip snmp tftp When HELPERS is specified on a system running Kernel 3.5.0 or later, automatic association of helpers to connections is disabled. HIGH_ROUTE_MARKS={Yes|No} Deprecated in Shorewall 4.4.26 in favor of PROVIDER_OFFSET. Prior to version 3.2.0, it was not possible to use connection marking in shorewall-tcrules(5) if you had a multi-ISP configuration that uses the track option. You may set HIGH_ROUTE_MARKS=Yes in to effectively divide the packet mark and connection mark into two mark fields. The width of the fields are determined by the setting of WIDE_TC_MARKS. If WIDE_TC_MARKS=No (the default): The MARK field in the providers file must have a value that is less than 65536 and that is a multiple of 256 (using hex representation, the values are 0x0100-0xFF00 with the low-order 8 bits being zero). You may only set those mark values in the PREROUTING chain. Marks used for traffic shaping must still be in the range of 1-255 and may still not be set in the PREROUTING chain. When WIDE_TC_MARKS=Yes: The MARK field in the providers file must have a value that is a multiple of 65536 (using hex representation, the values are 0x010000-0xFF0000 with the low-order 16 bits being zero). You may only set those mark values in the PREROUTING chain. Marks used for traffic shaping must be in the range of 1-16383 and may still not be set in the PREROUTING chain. Regardless of the setting of WIDE_TC_MARKS, when you SAVE or RESTORE in tcrules, only the TC mark value is saved or restored. Shorewall handles saving and restoring the routing (provider) marks. IGNOREUNKNOWNVARIABLES=[Yes|No] Added in Shorewall 4.5.11. Normally, if an unknown shell variable is encountered in a configuration file (except in ?IF and ?ELSIF directives), the compiler raises a fatal error. If IGNOREUNKNOWNVARIABLES is set to Yes, then such variables simply expand to an empty string. Default is No. IMPLICIT_CONTINUE={Yes|No} When this option is set to Yes, it causes subzones to be treated differently with respect to policies. Subzones are defined by following their name with ":" and a list of parent zones (in shorewall-zones(5)). Normally, you want to have a set of special rules for the subzone and if a connection doesn't match any of those subzone-specific rules then you want the parent zone rules and policies to be applied; see shorewall-nesting(5). With IMPLICIT_CONTINUE=Yes, that happens automatically. If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then subzones are not subject to this special treatment. With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden by including an explicit policy (one that does not specify "all" in either the SOURCE or the DEST columns). INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE] Added in Shorewall 4.5.13. Shorewall has traditionally passed INVALID packets through the NEW section of shorewall-rules (5). When a packet in INVALID state fails to match any rule in the INVALID section, the packet is disposed of based on this setting. The default value is CONTINUE for compatibility with earlier versions. INVALID_LOG_LEVEL=log-level Added in Shorewall 4.5.13. Packets in the INVALID state that do not match any rule in the INVALID section of shorewall-rules (5) are logged at this level. The default value is empty which means no logging is performed. IP=[pathname] If specified, gives the pathname of the 'ip' executable. If not specified, 'ip' is assumed and the utility will be located using the current PATH setting. IP_FORWARDING=[On|Off|Keep] This parameter determines whether Shorewall enables or disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). Possible values are: On or on packet forwarding will be enabled. Off or off packet forwarding will be disabled. Keep or keep Shorewall will neither enable nor disable packet forwarding.
If this variable is not set or is given an empty value (IP_FORWARD="") then IP_FORWARD=On is assumed.
IPSECFILE=zones This option indicates that zone-related ipsec information is found in the zones file (shorewall-zones(5)). The option indicates to the compiler that this is not a legacy configuration where the ipsec information was contained in a separate file. The value of this option must not be changed and the option must not be deleted. IPSET=[pathname] If specified, gives the pathname of the 'ipset' executable. If not specified, 'ipset' is assumed and the utility will be located using the current PATH setting. IPSET_WARNINGS={Yes|No} Added in Shorewall 4.5.2. Default is Yes. When set, causes the rules compiler to issue a warning when: The compiler is being run by root and an ipset specified in the configuration does not exists. Only one warning is issued for each missing ipset. When [src] is specified in a destination column and when [dst] is specified in a source column. IPTABLES=[pathname] This parameter names the iptables executable to be used by Shorewall. If not specified or if specified as a null value, then the iptables executable located using the PATH option is used. Regardless of how the iptables utility is located (specified via IPTABLES= or located via PATH), Shorewall uses the iptables-restore and iptables-save utilities from that same directory. KEEP_RT_TABLES={Yes|No} When set to , this option prevents generated scripts from altering the /etc/iproute2/rt_tables database when there are entries in /etc/shorewall/providers. If you set this option to while Shorewall (Shorewall-lite) is running, you should remove the file /var/lib/shorewall/rt_tables (/var/lib/shorewall-lite/rt_tables) before your next stop, refresh, restore on restart command. The default is KEEP_RT_TABLES=No. LEGACY_FASTSTART={Yes|No} Added in Shorewall 4.4.20. If not specified, the default is Yes which preserves the legacy behavior of start -f (the modification times of the files in /etc/shorewall are compare with that of /var/lib/shorewall/restore). If set to No, then the times are compared with that of /var/lib/shorewall/firewall, which is consistent with the way that restart -f works. LOAD_HELPERS_ONLY={Yes|No} Added in Shorewall 4.4.7. When set to Yes, restricts the set of modules loaded by shorewall to those listed in /var/lib/shorewall/helpers and those that are actually used. When not set, or set to the empty value, LOAD_HELPERS_ONLY=No is assumed. LOCKFILE=[pathname] Specifies the name of the Shorewall lock file, used to prevent simultaneous state-changing commands. If not specified, ${VARDIR}/shorewall/lock is assumed (${VARDIR} is normally /var/lib but can be changed when Shorewall-core is installed -- see the output of shorewall show vardir). LOG_MARTIANS=[Yes|No|Keep] If set to Yes or yes, sets /proc/sys/net/ipv4/conf/*/log_martians to 1 with the exception of /proc/sys/net/ipv4/conf/all/log_martians which is set to 0. The default value is Yes which sets both of the above to one. If you do not enable martian logging for all interfaces, you may still enable it for individual interfaces using the logmartians interface option in shorewall-interfaces(5). The value Keep causes Shorewall to ignore the option. If the option is set to Yes, then martians are logged on all interfaces. If the option is set to No, then martian logging is disabled on all interfaces except those specified in shorewall-interfaces(5). LOG_VERBOSITY=[number] This option controls the amount of information logged to the file specified in the STARTUP_LOG option. Values are: -1 - Logging is disabled 0 - Silent. Only error messages are logged. 1 - Major progress messages logged. 2 - All progress messages logged If not specified, then -1 is assumed. LOGALLNEW=[log-level] This option is intended for use as a debugging aid. When set to a log level, this option causes Shorewall to generate a logging rule as the first rule in each builtin chain. The table name is used as the chain name in the log prefix. The chain name is used as the target in the log prefix.
For example, using the default LOGFORMAT, the log prefix for logging from the nat table's PREROUTING chain is: Shorewall:nat:PREROUTING To help insure that all packets in the NEW state are logged, rate limiting (LOGBURST and LOGRATE) should be disabled when using LOGALLNEW. Use LOGALLNEW at your own risk; it may cause high CPU and disk utilization and you may not be able to control your firewall after you enable this option. Do not use this option if the resulting log messages will be sent to another system.
LOGFILE=[pathname] This parameter tells the /sbin/shorewall program where to look for Shorewall messages when processing the dump, logwatch, show log, and hits commands. If not assigned or if assigned an empty value, /var/log/messages is assumed. For further information, see http://www.shorewall.net/shorewall_logging.html. LOGFORMAT=["formattemplate"] The value of this variable generate the --log-prefix setting for Shorewall logging rules. It contains a “printf” formatting template which accepts three arguments (the chain name, logging rule number (optional) and the disposition). To use LOGFORMAT with fireparse, set it as: LOGFORMAT="fp=%s:%d a=%s " If the LOGFORMAT value contains the substring “%d” then the logging rule number is calculated and formatted in that position; if that substring is not included then the rule number is not included. If not supplied or supplied as empty (LOGFORMAT="") then “Shorewall:%s:%s:” is assumed. The setting of LOGFORMAT has an effect of the permitted length of zone names. See shorewall-zones (5). LOGLIMIT=[[{s|d}:]rate/{sec|min|hour|day}[:burst]] Added in Shorewall 4.4.12. Limits the logging rate, either overall, or by source or destination IP address. If the value starts with 's:' then logging is limited per source IP. If the value starts with 'd:', then logging is limited per destination IP. Otherwise, the overall logging rate is limited. If burst is not specified, then a value of 5 is assumed. LOGBURST=[burst] Deprecated in Shorewall 4.4.12. LOGRATE=[rate/{minute|second}] Deprecated in Shorewall 4.4.12. These options are ignored when LOGLIMIT is specified. These parameters set the match rate and initial burst size for logged packets. Please see iptables(8) for a description of the behavior of these parameters (the iptables option --limit is set by LOGRATE and --limit-burst is set by LOGBURST). If both parameters are set empty, no rate-limiting will occur. If you supply one of these, then you should also supply the other. Example: LOGRATE=10/minute LOGBURST=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, 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. LOGTAGONLY=[Yes|No] Using the default LOGFORMAT, chain names may not exceed 11 characters or truncation of the log prefix may occur. Longer chain names may be used with log tags if you set LOGTAGONLY=Yes. With LOGTAGONLY=Yes, if a log tag is specified then the tag is included in the log prefix in place of the chain name. Beginning with Shorewall 4.5.12, when LOGTAGONLY=Yes, you have more control over the generated log prefix. Beginning with that release, the tag is interpreted as a chain name and a disposition separated by a comma. So this rule: #ACTION SOURCE DEST LOG:info:foo,bar net fw would generate the following log prefix when using the default LOGFORMAT setting: Shorewall:foo:bar: Similarly, #ACTION SOURCE DEST LOG:info:,bar net fw would generate Shorewall:net2fw:bar: MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT] Determines the disposition of connections requests that fail MAC Verification and must have the value ACCEPT (accept the connection request anyway), REJECT (reject the connection request) or DROP (ignore the connection request). If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed. A_DROP and A_REJECT are audited versions of DROP and REJECT respectively and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel and iptables. MACLIST_LOG_LEVEL=[log-level] Determines the syslog level for logging connection requests that fail MAC Verification. The value must be a valid syslogd log level. If you don't want to log these connection requests, set to the empty value (e.g., MACLIST_LOG_LEVEL=""). MACLIST_TABLE=[filter|mangle] Normally, MAC verification occurs in the filter table (INPUT and FORWARD) chains. When forwarding a packet from an interface with MAC verification to a bridge interface, that doesn't work. This problem can be worked around by setting MACLIST_TABLE=mangle which will cause Mac verification to occur out of the PREROUTING chain. Because REJECT isn't available in that environment, you may not specify MACLIST_DISPOSITION=REJECT or MACLIST_DISPOSITION=A_REJECT with MACLIST_TABLE=mangle. MACLIST_TTL=[number] The performance of configurations with a large numbers of entries in shorewall-maclist(5) can be improved by setting the MACLIST_TTL variable in shorewall.conf(5). If your iptables and kernel support the "Recent Match" (see the output of "shorewall check" near the top), you can cache the results of a 'maclist' file lookup and thus reduce the overhead associated with MAC Verification. When a new connection arrives from a 'maclist' interface, the packet passes through then list of entries for that interface in shorewall-maclist(5). If there is a match then the source IP address is added to the 'Recent' set for that interface. Subsequent connection attempts from that IP address occurring within $MACLIST_TTL seconds will be accepted without having to scan all of the entries. After $MACLIST_TTL from the first accepted connection request from an IP address, the next connection request from that IP address will be checked against the entire list. If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not be cached). MANGLE_ENABLED=[Yes|No] Determines whether Shorewall will generate rules in the Netfilter mangle table. Setting MANGLE_ENABLED=No disables all Shorewall features that require the mangle table. The default is MANGLE_ENABLED=Yes. MAPOLDACTIONS=[Yes|No] This option is included for compatibility with old Shorewall configuration. New installs should always have MAPOLDACTIONS=No. MARK_IN_FORWARD_CHAIN=[Yes|No] If your kernel has a FORWARD chain in the mangle table, you may set MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the tcrules file to occur in that chain rather than in the PREROUTING chain. This permits you to mark inbound traffic based on its destination address when DNAT is in use. To determine if your kernel has a FORWARD chain in the mangle table, use the /sbin/shorewall show mangle command; if a FORWARD chain is displayed then your kernel will support this option. If this option is not specified or if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed. MASK_BITS=[number] Added in Shorewall 4.4.26. Number of bits on the right of the 32-bit packet mark to be masked when clearing the traffic shaping mark. Must be >= TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET > 0). Default value and the default values of the other mark layout options is determined as follows: Default Packet Mark Layout 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
MODULE_SUFFIX=["extension ..."] The value of this option determines the possible file extensions of kernel modules. The default value is "ko ko.gz o o.gz gz". MODULESDIR=[pathname[:pathname]...] This parameter specifies the directory/directories where your kernel netfilter modules may be found. If you leave the variable empty, Shorewall will supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter" in versions of Shorewall prior to 3.2.4 and "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter:/lib/modules/`uname -r`/kernel/net/ipv4/netfilter" in later versions. MULTICAST=[Yes|No] This option will normally be set to 'No' (the default). It should be set to 'Yes' under the following circumstances: You have an interface that has parallel zones defined via /etc/shorewall/hosts. You want to forward multicast packets to two or more of those parallel zones. In such cases, you will configure a network on each zone receiving multicasts. MUTEX_TIMEOUT=[seconds] The value of this variable determines the number of seconds that programs will wait for exclusive access to the Shorewall lock file. After the number of seconds corresponding to the value of this variable, programs will assume that the last program to hold the lock died without releasing the lock. If not set or set to the empty value, a value of 60 (60 seconds) is assumed. An appropriate value for this parameter would be twice the length of time that it takes your firewall system to process a shorewall restart command. NFACCT=[pathname] Added in Shorewall 4.5.7. Specifies the pathname of the nfacct utility. If not specified, Shorewall will use the PATH setting to find the program. NULL_ROUTE_RFC1918=[Yes|No|blackhole|unreachable|prohibit] When set to Yes, causes Shorewall to null-route the IPv4 address ranges reserved by RFC1918. The default value is 'No'. When combined with route filtering (ROUTE_FILTER=Yes or in shorewall-interfaces(5)), this option ensures that packets with an RFC1918 source address are only accepted from interfaces having known routes to networks using such addresses. Beginning with Shorewall 4.5.15, you may specify , or to set the type of route to be created. See http://www.shorewall.net/MultiISP.html#null_routing. OPTIMIZE=[value] The specified value enables certain optimizations. Each optimization category is associated with a power of two. To enable multiple optimization categories, simply add their corresponding numbers together. Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to enable all optimization categories, and you may also specify OPTIMIZE=None to disable optimization. Optimization category 1 - Traditionally, Shorewall has created rules for the complete matrix of host groups defined by the zones, interfaces and hosts files. Any traffic that didn't correspond to an element of that matrix was rejected in one of the built-in chains. When the matrix is sparse, this results in lots of largely useless rules. These extra rules can be eliminated by setting the 1 bit in OPTIMIZE. The 1 bit setting also controls the suppression of redundant wildcard rules (those specifying "all" in the SOURCE or DEST column). A wildcard rule is considered to be redundant when it has the same ACTION and Log Level as the applicable policy. Optimization level 1 is ignored when optimization level 4 is also selected, since level 4 performs similar optimizations in a more robust way. Optimization category 2 - Added in Shorewall 4.4.7. When set, suppresses superfluous ACCEPT rules in a policy chain that implements an ACCEPT policy. Any ACCEPT rules that immediately precede the final blanket ACCEPT rule in the chain are now omitted. Optimization category 4 - Added in Shorewall 4.4.7. When set, causes short chains (those with less than 2 rules) to be optimized away. The following chains are excluded from optimization: accounting chains (unless OPTIMIZE_ACCOUNTING=Yes) action chains (user-defined) 'blacklst' chain dynamic forwardUPnP UPnP (nat table) Additionally: If a built-in chain has a single rule that branches to a second chain, then the rules from the second chain are moved to the built-in chain and the target chain is omitted. Chains with no references are deleted. Accounting chains are subject to optimization if the OPTIMIZE_ACCOUNTING option is set to 'Yes'. If a chain ends with an unconditional branch to a second chain (other than to 'reject'), then the branch is deleted from the first chain and the rules from the second chain are appended to it. An additional optimization was added in Shorewall 4.5.4. If the last rule in a chain is an unqualified jump to a simple target, then all immediately preceding rules with the same simple target are omitted. For example, consider this chain: -A fw-net -p udp --dport 67:68 -j ACCEPT -A fw-net -p udp --sport 1194 -j ACCEPT -A fw-net -p 41 -j ACCEPT -A fw-net -j ACCEPT Since all of the rules are jumps to the simple target ACCEPT, this chain is totally optimized away and jumps to the chain are replace with jumps to ACCEPT. Optimization category 8 - Added in Shorewall 4.4.9. When set, causes chains with identical rules to be collapsed into a single chain. Optimization category 16 - Added in Shorewall 4.4.26. When set, causes sequences of compatible rules to be combined into a single rule. Rules are considered compatible if they differ only in their destination ports and comments. A sequence of compatible rules is often generated when macros are invoked in sequence. The ability to combine adjacent rules is limited by two factors: Destination port lists may only be combined up to a maximum of 15 ports, where a port-pair counts as two ports. Rules may only be combined until the length of their concatenated comment reaches 255 characters. When either of these limits would be exceeded, the current combined rule is emitted and the compiler attempts to combine rules beginning with the one that would have exceeded the limit. Adjacent combined comments are separated by ', '. Empty comments at the front of a group of combined comments are replaced by 'Others and'. Empty comments at the end of a group of combined comments are replaced by 'and others'. Beginning in Shorewall 4.5.10, this option also suppresses duplicate adjacent rules and duplicate non-adjacent rules that don't include mark, connmark, dscp, ecn, set, tos or u32 matches. Example 1: Rules with comments "FOO", <empty> and "BAR" would result in the combined comment "FOO and others, BAR". Example 2: Rules with comments <empty>, "FOO" and "BAR" would result in the combined comment "Others and FOO, BAR". Note: Optimize level 16 requires "Extended Multi-port Match" in your iptables and kernel. The default value is zero which disables all optimizations. OPTIMIZE_ACCOUNTING=[Yes|No] Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting changes are subject to optimization (OPTIMIZE=4,5,6 or 7). If not specified or set to the empty value, OPTIMIZE_ACCOUNTING=No is assumed. PATH=pathname[:pathname]... Determines the order in which Shorewall searches directories for executable files. PERL=pathname Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl executable. Default is /usr/bin/perl. If the pathname specified by this option does not exist or the named file is not executable, then Shorewall falls back to /usr/bin/perl/ PROVIDER_BITS=[number] Added in Shorewall 4.4.26. The number of bits in the 32-bit packet mark to be used for provider numbers. May be zero. See MASK_BITS above for default value. PROVIDER_OFFSET=[number]If Added in Shorewall 4.4.26. The offset from the right (low-order end) of the provider number field in the 32-bit packet mark. If non-zero, must be >= TC_BITS (Shorewall automatically adjusts PROVIDER_OFFSET's value). PROVIDER_OFFSET + PROVIDER_BITS + ZONE_BITS must be < 32. See MASK_BITS above for default value. RCP_COMMAND="command" RSH_COMMAND="command" Earlier generations of Shorewall Lite required that remote root login via ssh be enabled in order to use the load and reload commands. Beginning with release 3.9.5, you may define an alternative means for accessing the remote firewall system. In that release, two new options were added to shorewall.conf: RSH_COMMAND RCP_COMMAND The default values for these are as follows: RSH_COMMAND: ssh ${root}@${system} ${command} RCP_COMMAND: scp ${files} ${root}@${system}:${destination} Shell variables that will be set when the commands are invoked are as follows: root - root user. Normally but may be overridden using the '-r' option. system - The name/IP address of the remote firewall system. command - For RSH_COMMAND, the command to be executed on the firewall system. files - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system. destination - The directory on the remote system that the files are to be copied into. RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE] Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed RELATED packets that don't match any rule in the RELATED section of shorewall-rules (5). Concern about the safety of this practice resulted in the addition of this option. When a packet in RELATED state fails to match any rule in the RELATED section, the packet is disposed of based on this setting. The default value is ACCEPT for compatibility with earlier versions. RELATED_LOG_LEVEL=log-level Added in Shorewall 4.4.27. Packets in the related state that do not match any rule in the RELATED section of shorewall-rules (5) are logged at this level. The default value is empty which means no logging is performed. REJECT_ACTION=action Added in Shorewall 4.5.21. When a REJECT target is specified, Shorewall normally handles the response as follows: If the destination address of the packet is a broadcast or multicast address, the packet is dropped. if the protocol is ICMP (2) then the packet is dropped. if the protocol is TCP (6) then the packet is rejected with an RST. if the protocol is UDP (17) then the packet is rejected with an 'port-unreachable' ICMP (ICMP6). if the protocol is ICMP (1) then the packet is rejected with a 'host-unreachable' ICMP. otherwise, the packet is rejected with a 'host-prohibited' ICMP. You can modify this behavior by implementing your own action that handles REJECT and specifying it's name in this option. The nolog and inline options will automatically be assumed for the specified action. The following action implements the standard behavior: ?format 2 #TARGET SOURCE DEST PROTO Broadcast(DROP) - - - DROP - - 2 INLINE - - 6 ; -j REJECT --reject-with tcp-reset ?if __ENHANCED_REJECT INLINE - - 17 ; -j REJECT ?if __IPV4 INLINE - - 1 ; -j REJECT --reject-with icmp-host-unreachable INLINE - - - ; -j REJECT --reject-with icmp-host-prohibited ?else INLINE - - 58 ; -j REJECT --reject-with icmp6-addr-unreachable INLINE - - - ; -j REJECT --reject-with icmp6-adm-prohibited ?endif ?else INLINE - - - ; -j REJECT ?endif REQUIRE_INTERFACE=[Yes|No] Added in Shorewall 4.4.10. The default is No. If set to Yes, at least one optional interface must be up in order for the firewall to be in the started state. Intended to be used with the Shorewall Init Package. RESTORE_DEFAULT_ROUTE=[Yes|No] This option determines whether to restore the default route saved when here are 'balance' providers defined but all of them are down. The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the pre-4.2.6 behavior. RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a default route in the main table (USE_DEFAULT_RT=No) or in the default table (USE_DEFAULT_RT=Yes) when there are no balance providers available. In that case, RESTORE_DEFAULT_ROUTE=No will cause any default route in the relevant table to be deleted. RESTORE_ROUTEMARKS=[Yes|No] Added in Shorewall 4.5.9. When set to Yes (the default), provider marks are restored unconditionally at the top of the mangle OUTPUT and PREROUTING chains, even if the saved mark is zero. When this option is set to No, the mark is restored even when it is zero. If you have problems with IPSEC ESP packets not being routed correctly on output, try setting this option to No. RESTOREFILE=filename Specifies the simple name of a file in /var/lib/shorewall to be used as the default restore script in the shorewall save, shorewall restore, shorewall forget and shorewall -f start commands. RETAIN_ALIASES={Yes|No} During shorewall start, IP addresses to be added as a consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly deleted when shorewall-nat(5) and shorewall-masq(5) are processed then are re-added later. This is done to help ensure that the addresses can be added with the specified labels but can have the undesirable side effect of causing routes to be quietly deleted. When RETAIN_ALIASES is set to Yes, existing addresses will not be deleted. Regardless of the setting of RETAIN_ALIASES, addresses added during shorewall start are still deleted at a subsequent shorewall stop or shorewall restart. ROUTE_FILTER=[Yes|No|Keep] If this parameter is given the value Yes or yes then route filtering (anti-spoofing) is enabled on all network interfaces which are brought up while Shorewall is in the started state. The default value is no. The value Keep causes Shorewall to ignore the option. If the option is set to Yes, then route filtering occurs on all interfaces. If the option is set to No, then route filtering is disabled on all interfaces except those specified in shorewall-interfaces(5). If you need to disable route filtering on any interface, then you must set ROUTE_FILTER=No then set routefilter=1 or routefilter=2 on those interfaces where you want route filtering. See shorewall-interfaces(5) for additional details. RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT] Added in Shorewall 4.5.7. Determines the disposition of packets entering from interfaces the option (see shorewall-interfaces(5)). Packets disposed of by this option are those whose response packets would not be sent through the same interface receiving the packet. RPFILTER_LOG_LEVEL=log-level Added in shorewall 4.5.7. Determines the logging of packets disposed via the RPFILTER_DISPOSITION. The default value is . SAVE_ARPTABLES={Yes|No} Added in Shorewall 4.5.12. If SAVE_ARPTABLES=Yes, then the current arptables contents will be saved by shorewall save command and restored by shorewall restore command. Default value is No. SAVE_IPSETS={Yes|No} Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the current contents of your ipsets will be saved by the shorewall stop and shorewall save commands and restored by the shorewall start and shorewall restore commands. SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT] Added in Shorewall 4.4.20. Determines the disposition of packets matching the option (see shorewall-interfaces(5)) and of hairpin packets on interfaces without the option. Hairpin packets are packets that are routed out of the same interface that they arrived on. interfaces without the routeback option. SFILTER_LOG_LEVEL=log-level Added on Shorewall 4.4.20. Determines the logging of packets matching the option (see shorewall-interfaces(5)) and of hairpin packets on interfaces without the option. Hairpin packets are packets that are routed out of the same interface that they arrived on. interfaces without the routeback option. The default is . If you don't wish for these packets to be logged, use SFILTER_LOG_LEVEL=none. SHOREWALL_SHELL=[pathname] This option is used to specify the shell program to be used to run the Shorewall compiler and to interpret the compiled script. If not specified or specified as a null value, /bin/sh is assumed. Using a light-weight shell such as ash or dash can significantly improve performance. SMURF_DISPOSITION=[DROP|A_DROP] Added in Shorewall 4.4.20. The default setting is DROP which causes smurf packets (see the nosmurfs option in shorewall-interfaces(5)) to be dropped. A_DROP causes the packets to be audited prior to being dropped and requires AUDIT_TARGET support in the kernel and iptables. SMURF_LOG_LEVEL=[log-level] Specifies the logging level for smurf packets (see the nosmurfs option in shorewall-interfaces(5)). If set to the empty value ( SMURF_LOG_LEVEL="" ) then smurfs are not logged. STARTUP_ENABLED={Yes|No} Determines if Shorewall is allowed to start. As released from shorewall.net, this option is set to No. When set to Yes or yes, Shorewall may be started. Used as a guard against Shorewall being accidentally started before it has been configured. STARTUP_LOG=[pathname] If specified, determines where Shorewall will log the details of each start, restart and refresh command. Logging verbosity is determined by the setting of LOG_VERBOSITY above. SUBSYSLOCK=[pathname] This parameter should be set to the name of a file that the firewall should create if it starts successfully and remove when it stops. Creating and removing this file allows Shorewall to work with your distribution's initscripts. For RedHat and OpenSuSE, this should be set to /var/lock/subsys/shorewall. For Debian, the value is /var/lock/shorewall and in LEAF it is /var/run/shorewall. TC=[pathname] If specified, gives the pathname of the 'tc' executable. If not specified, 'tc' is assumed and the utility will be located using the current PATH setting. TC_BITS=[number] The number of bits at the low end of the 32-bit packet mark to be used for traffic shaping marking. May be zero. See MASK_BITS above for default value. TC_ENABLED=[Yes|No|Internal|Simple|Shared] If you say Yes or yes here, Shorewall will use a script that you supply to configure traffic shaping. The script must be named 'tcstart' and must be placed in a directory on your CONFIG_PATH. If you say No or no then traffic shaping is not enabled. If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later), simple traffic shaping using shorewall-tcinterfaces(5) and shorewall-tcpri(5) is enabled. If you set TC_ENABLED=Internal or internal or leave the option empty then Shorewall will use its builtin traffic shaper (tc4shorewall written by Arne Bernin. Beginning with Shorewall 4.4.15, you can set TC_ENABLED=Shared. This allows you to configure the tcdevices and tcclasses in your Shorewall6 configuration yet make them available to the compiler when compiling your Shorewall configuration. In addition to setting TC_ENABLED=Shared, you need to create symbolic links from your Shorewall configuration directory (normally /etc/shorewall/) to the tcdevices and tcclasses files in your Shorewall6 configuration directory (normally /etc/shorewall6/). TC_EXPERT={Yes|No} Normally, Shorewall tries to protect users from themselves by preventing PREROUTING and OUTPUT tcrules from being applied to packets that have been marked by the 'track' option in shorewall-providers(5). If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall will not include these cautionary checks. TC_PRIOMAP=map Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS field to priority bands. See shorewall-tcpri(5). The map consists of 16 space-separated digits with values 1, 2 or 3. A value of 1 corresponds to Linux priority 0, 2 to Linux priority 1, and 3 to Linux Priority 2. The first entry gives the priority of TOS value 0, the second of TOS value 1, and so on. See tc-prio(8) for additional information. The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2". TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT] Determines the disposition of TCP packets that fail the checks enabled by the tcpflags interface option (see shorewall-interfaces(5)) and must have a value of ACCEPT (accept the packet), REJECT (send an RST response) or DROP (ignore the packet). If not set or if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed. A_DROP and A_REJECT are audited versions of DROP and REJECT respectively and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel and iptables. TCP_FLAGS_LOG_LEVEL=[log-level] Determines the syslog level for logging packets that fail the checks enabled by the tcpflags interface option. The value must be a valid syslogd log level. If you don't want to log these packets, set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL=""). TRACK_PROVIDERS={Yes|No} Added in Shorewall 4.4.3. When set to Yes, causes the option to be assumed on all providers defined in shorewall-providers(5). May be overridden on an individual provider through use of the option. The default value is 'No'. Beginning in Shorewall 4.4.6, setting this option to 'Yes' also simplifies PREROUTING rules in shorewall-tcrules(5). Previously, when TC_EXPERT=No, packets arriving through 'tracked' provider interfaces were unconditionally passed to the PREROUTING tcrules. This was done so that tcrules could reset the packet mark to zero, thus allowing the packet to be routed using the 'main' routing table. Using the main table allowed dynamic routes (such as those added for VPNs) to be effective. The rtrules file was created to provide a better alternative to clearing the packet mark. As a consequence, passing these packets to PREROUTING complicates things without providing any real benefit. Beginning with Shorewall 4.4.6, when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving through 'tracked' interfaces will not be passed to the PREROUTING rules. Since TRACK_PROVIDERS was just introduced in 4.4.3, this change should be transparent to most, if not all, users. TRACK_RULES={Yes|No} Added in Shorewall 4.5.20. If set to Yes, causes the compiler to add a comment to iptables rules to indicate the file name and line number of the configuration entry that generated the rule. If set to No (the default), then no such comments are added. Setting this option to Yes requires the Comments capability in iptables and kernel. UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE] Added in Shorewall 4.5.13. Shorewall has traditionally passed UNTRACKED packets through the NEW section of shorewall-rules (5). When a packet in UNTRACKED state fails to match any rule in the UNTRACKED section, the packet is disposed of based on this setting. The default value is CONTINUE for compatibility with earlier versions. UNTRACKED_LOG_LEVEL=log-level Added in Shorewall 4.5.13. Packets in the UNTRACKED state that do not match any rule in the UNTRACKED section of shorewall-rules (5) are logged at this level. The default value is empty which means no logging is performed. USE_DEFAULT_RT=[Yes|No] When set to 'Yes', this option causes the Shorewall multi-ISP feature to create a different set of routing rules which are resilient to changes in the main routing table. Such changes can occur for a number of reasons, VPNs going up and down being an example. The idea is to send packets through the main table prior to applying any of the Shorewall-generated routing rules. So changes to the main table will affect the routing of packets by default. When USE_DEFAULT_RT=Yes: Both the DUPLICATE and the COPY columns in providers(5) file must remain empty (or contain "-"). The default route is added to the the 'default' table rather than to the main table. balance is assumed unless loose is specified. Packets are sent through the main routing table by a rule with priority 999. In routing_rules(5), the range 1-998 may be used for inserting rules that bypass the main table. All provider gateways must be specified explicitly in the GATEWAY column. detect may not be specified. detect may be specified for interfaces whose configuration is managed by dhcpcd. Shorewall will use dhcpcd's database to find the interface's gateway. You should disable all default route management outside of Shorewall. If a default route is added to the main table while Shorewall is started, then all policy routing will stop working (except for those routing rules in the priority range 1-998). If USE_DEFAULT_RT is not set or if it is set to the empty string then USE_DEFAULT_RT=No is assumed. USE_PHYSICAL_NAMES=[Yes|No] Added in Shorewall 4.4.27. Normally, when Shorewall creates a Netfilter chain that relates to an interface, it uses the interface's logical name as the base of the chain name. For example, if the logical name for an interface is OAKLAND, then the input chain for traffic arriving on that interface would be 'OAKLAND_in'. If this option is set to Yes, then the physical name of the interface will be used the base of the chain name. USE_RT_NAMES=[Yes|No] Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use routing table (provider) names in the generated script rather than table numbers. When set to 'No' (the default), routing table numbers will be used. If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must insure that all of your providers have entries in /etc/iproute2/rt_tables as well as the following entries: 255 local 254 main 253 default 250 balance 0 unspec Without these entries, the firewall will fail to start. VERBOSITY=[number] Shorewall has traditionally been very noisy (produced lots of output). You may set the default level of verbosity using the VERBOSITY OPTION. Values are: 0 - Silent. You may make it more verbose using the -v option 1 - Major progress messages displayed 2 - All progress messages displayed (pre Shorewall-3.2.0 behavior) If not specified, then 2 is assumed. WARNOLDCAPVERSION=[Yes|No] Added in Shorewall 4.5.12. When set to Yes (the default), the compiler issues a warning when it finds a capabilities file that doesn't specify all of the capabilities supported by the compiler. When WARNOLDCAPVERSION is set to No, no warning is issued. WIDE_TC_MARKS={Yes|No} Deprecated in Shorewall 4.4.26 in favor of TC_BITS and MASK_BITS. When set to No (the default), traffic shaping marks are 8 bytes wide (possible values are 1-255). When WIDE_TC_MARKS=Yes, traffic shaping marks are 14 bytes wide (values 1-16383). The setting of WIDE_TC_MARKS also has an effect on the HIGH_ROUTE_MARKS option (see above). ZONE_BITS=[number] Added in Shorewall 4.4.26. When non-zero, enables automatic packet marking by source zone and determines the number of bits in the 32-bit packet mark to be used for the zone mark. Default value is 0. ZONE2ZONE={|} Added in Shorewall 4.4.4. This option determines how Shorewall constructs chain names involving zone names and/or 'all'. The default is '2' (e.g., fw2net).
FILES /etc/shorewall/shorewall.conf See ALSO shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcinterfaces(5), shorewall-tcpri(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-maclist.xml0000644000175000017500000001065012222401136023165 0ustar teastepteastep shorewall-maclist 5 maclist Shorewall MAC Verification file /etc/shorewall/maclist Description This file is used to define the MAC addresses and optionally their associated IP addresses to be allowed to use the specified interface. The feature is enabled by using the maclist option in the shorewall-interfaces(5) or shorewall-hosts(5) configuration file. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). DISPOSITION - {ACCEPT|DROP|REJECT}[log-level] ACCEPT or DROP (if MACLIST_TABLE=filter in shorewall.conf(5), then REJECT is also allowed). If specified, the log-level causes packets matching the rule to be logged at that level. INTERFACE - interface Network interface to a host. MAC - address MAC address of the host -- you do not need to use the Shorewall format for MAC addresses here. If IP ADDRESSES is supplied then MAC can be supplied as a dash (-) IP ADDRESSES (addresses) - [address[,address]...] Optional - if specified, both the MAC and IP address must match. This column can contain a comma-separated list of host and/or subnet addresses. If your kernel and iptables have iprange match support then IP address ranges are also allowed. Similarly, if your kernel and iptables include ipset support than set names (prefixed by "+") are also allowed. FILES /etc/shorewall/maclist See ALSO http://shorewall.net/MAC_Validation.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-zones.xml0000644000175000017500000004233712222401136022676 0ustar teastepteastep shorewall-zones 5 zones Shorewall zone declaration file /etc/shorewall/zones Description The /etc/shorewall/zones file declares your network zones. You specify the hosts in each zone through entries in /etc/shorewall/interfaces or /etc/shorewall/hosts. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ZONE - zone[:parent-zone[,parent-zone]...] Name of the zone. Must start with a letter and consist of letters, digits or '_'. The names "all", "none", "any", "SOURCE" and "DEST" are reserved and may not be used as zone names. The maximum length of a zone name is determined by the setting of the LOGFORMAT option in shorewall.conf(5). With the default LOGFORMAT, zone names can be at most 5 characters long.
The maximum length of an iptables log prefix is 29 bytes. As explained in shorewall.conf (5), the default LOGPREFIX formatting string is “Shorewall:%s:%s:” where the first %s is replaced by the chain name and the second is replaced by the disposition. The default formatting string has 12 fixed characters ("Shorewall" and three colons). The longest of the standard dispositions are ACCEPT and REJECT which have 6 characters each. The canonical name for the chain containing the rules for traffic going from zone 1 to zone 2 is "<zone 1>2<zone 2>" or "<zone 1>-<zone 2>". So if M is the maximum zone name length, such chains can have length 2*M + 1. 12 + 6 + 2*M + 1 = 29 which reduces to 2*M = 29 - 12 - 6 - 1 = 10 or M = 5
The order in which Shorewall matches addresses from packets to zones is determined by the order of zone declarations. Where a zone is nested in one or more other zones, you may either ensure that the nested zone precedes its parents in this file, or you may follow the (sub)zone name by ":" and a comma-separated list of the parent zones. The parent zones must have been declared in earlier records in this file. See shorewall-nesting(5) for additional information. Example: #ZONE TYPE OPTIONS IN OPTIONS OUT OPTIONS a ipv4 b ipv4 c:a,b ipv4 Currently, Shorewall uses this information to reorder the zone list so that parent zones appear after their subzones in the list. The IMPLICIT_CONTINUE option in shorewall.conf(5) can also create implicit CONTINUE policies to/from the subzone. Where an ipsec zone is explicitly included as a child of an ipv4 zone, the ruleset allows CONTINUE policies (explicit or implicit) to work as expected. In the future, Shorewall may make additional use of nesting information.
TYPE ipv4 This is the standard Shorewall zone type and is the default if you leave this column empty or if you enter "-" in the column. Communication with some zone hosts may be encrypted. Encrypted hosts are designated using the 'ipsec' option in shorewall-hosts(5). ipsec (or ipsec4) Communication with all zone hosts is encrypted. Your kernel and iptables must include policy match support. firewall Designates the firewall itself. You must have exactly one 'firewall' zone. No options are permitted with a 'firewall' zone. The name that you enter in the ZONE column will be stored in the shell variable $FW which you may use in other configuration files to designate the firewall zone. bport (or bport4) The zone is associated with one or more ports on a single bridge. vserver Added in Shorewall 4.4.11 Beta 2 - A zone composed of Linux-vserver guests. The zone contents must be defined in shorewall-hosts (5). Vserver zones are implicitly handled as subzones of the firewall zone. loopback Added in Shorewall 4.5.17. Normally, Shorewall treats the loopback interface (lo) in the following way: By default, all traffic through the interface is ACCEPTed. If a $FW -> $FW policy is defined or $FW -> $FW rules are defined, they are placed in a chain named ${FW}2${F2} or ${FW}-${FW} (e.g., 'fw2fw' or 'fw-fw' ) depending on the ZONE2ZONE setting in shorewall.conf(5). $FW -> $FW traffic is only filtered in the OUTPUT chain. By defining a loopback zone and associating it with the loopback interface in shorewall-interfaces(5), you can effect a slightly different model. Suppose that the loopback zone name is 'local'; then: Both $FW -> local and local -> $FW chains are created. The $FW -> local and local -> $FW policies may be different. Both $FW -> local and local -> $FW rules may be specified. Rules to/from the loopback zone and any zone other than the firewall zone are ignored with a warning. loopback zones may be nested within other loopback zones. local Added in Shorewall 4.5.17. local is the same as ipv4 with the exception that the zone is only accessible from the firewall and vserver zones. OPTIONS, IN OPTIONS and OUT OPTIONS (options, in_options, out_options) - [option[,option]...] A comma-separated list of options. With the exception of the and options, these only apply to TYPE zones. blacklist Added in Shorewall 4.4.13. May not be specified for firewall or vserver zones. When specified in the IN_OPTIONS column, causes all traffic from this zone to be passed against the src entries in shorewall-blacklist(5). When specified in the OUT_OPTIONS column, causes all traffic to this zone to be passed against the dst entries in shorewall-blacklist(5). Specifying this option in the OPTIONS column is equivalent to entering it in both of the IN_OPTIONS and OUT_OPTIONS column. dynamic_shared Added in Shorewall 4.5.9. May only be specified in the OPTIONS column and indicates that only a single ipset should be created for this zone if it has multiple dynamic entries in shorewall-hosts(5). Without this option, a separate ipset is created for each interface. reqid=number where number is specified using setkey(8) using the 'unique:number option for the SPD level. spi=<number> where number is the SPI of the SA used to encrypt/decrypt packets. proto=ah|esp|ipcomp IPSEC Encapsulation Protocol mss=number sets the MSS field in TCP packets. If you supply this option, you should also set FASTACCEPT=No in shorewall.conf(5) to insure that both the SYN and SYN,ACK packets have their MSS field adjusted. mode=transport|tunnel IPSEC mode tunnel-src=address[/mask] only available with mode=tunnel tunnel-dst=address[/mask] only available with mode=tunnel strict Means that packets must match all rules. next Separates rules; can only be used with strict The options in the OPTIONS column are applied to both incoming and outgoing traffic. The IN OPTIONS are applied to incoming traffic (in addition to OPTIONS) and the OUT OPTIONS are applied to outgoing traffic. If you wish to leave a column empty but need to make an entry in a following column, use "-".
FILES /etc/shorewall/zones See ALSO http://www.shorewall.net/Multiple_Zones.html. http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-nesting(8), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tcdevices.xml0000644000175000017500000003023212222401136023500 0ustar teastepteastep shorewall-tcdevices 5 tcdevices Shorewall Traffic Shaping Devices file /etc/shorewall/tcdevices Description Entries in this file define the bandwidth for interfaces on which you want traffic shaping to be enabled. If you do not plan to use traffic shaping for a device, don't put it in here as it limits the throughput of that device to the limits you set here. A note on the bandwidth definitions used in this file: don't use a space between the integer value and the unit: 30kbit is valid while 30 kbit is not. you can use one of the following units: kbps Kilobytes per second. mbps Megabytes per second. kbit Kilobits per second. mbit Megabits per second. bps or number Bytes per second. Only whole integers are allowed. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). INTERFACE - [number:]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 http://www.shorewall.net/FAQ.htm#faq18 You may NOT specify wildcards here, e.g. if you have multiple ppp interfaces, you need to put them all in here! If the device doesn't exist, a warning message will be issued during "shorewall [re]start" and "shorewall refresh" and traffic shaping configuration will be skipped for that device. Shorewall assigns a sequential interface number to each interface (the first entry in the file is interface 1, the second is interface 2 and so on) You can explicitly specify the interface number by prefixing the interface name with the number and a colon (":"). Example: 1:eth0. IN-BANDWIDTH (in_bandwidth) - {-|bandwidth[:burst]|~bandwidth[:interval:decay_interval]} The incoming bandwidth of that interface. Please note that you are not able to do traffic shaping on incoming traffic, as the traffic is already received before you could do so. But this allows you to define the maximum traffic allowed for this interface in total, if the rate is exceeded, the 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 to zero in which case Shorewall will not create an ingress qdisc.Must be set to zero if the REDIRECTED INTERFACES column is non-empty. The optional burst option was added in Shorewall 4.4.18. The default burst is 10kb. A larger burst can help make the bandwidth more accurate; often for fast lines, the enforced rate is well below the specified bandwidth. What is described above creates a rate/burst policing filter. Beginning with Shorewall 4.4.25, a rate-estimated policing filter may be configured instead. Rate-estimated filters should be used with Ethernet adapters that have Generic Receive Offload enabled by default. See Shorewall FAQ 97a. 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. OUT-BANDWIDTH (out_bandwidth) - bandwidth 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 in shorewall-tcclasses(5). Outgoing traffic above this rate will be dropped. OPTIONS - {-|{classify|htb|hfsc|linklayer={ethernet|atm|adsl}|tsize=tsize|mtu=mtu|mpu=mpu|overhead=overhead} ,...} ― When specified, Shorewall will not generate tc or Netfilter rules to classify traffic based on packet marks. You must do all classification using CLASSIFY rules in shorewall-tcrules(5). - Use the Hierarchical Token Bucket queuing discipline. This is the default. - Shorewall normally uses the Hierarchical Token Bucket queuing discipline. When is specified, the Hierarchical Fair Service Curves discipline is used instead (see tc-hfsc (7)). 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 (redirect)- [interface[,interface]...] May only be specified if the interface in the INTERFACE column is an Intermediate Frame Block (IFB) device. Causes packets that enter each listed interface to be passed through the egress filters defined for this device, thus providing a form of incoming traffic shaping. When this column is non-empty, the classify option is assumed.
Examples Example 1: 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 #INTERFACE IN-BANDWIDTH OUT-BANDWIDTH OPTIONS REDIRECTED # INTERFACES 1:ppp0 6000kbit 500kbit FILES /etc/shorewall/tcdevices See ALSO tc-hfsc (7) http://shorewall.net/traffic_shaping.htm http://shorewall.net/configuration_file_basics.htm#Pairs http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-exclusion.xml0000644000175000017500000001475012222401136023547 0ustar teastepteastep shorewall-exclusion 5 exclusion Exclude a set of hosts from a definition in a shorewall configuration file. address-or-range[,address-or-range] zone-name[,zone-name] Description The first form of exclusion is used when you wish to exclude one or more addresses from a definition. An exclamation point is followed by a comma-separated list of addresses. The addresses may be single host addresses (e.g., 192.168.1.4) or they may be network addresses in CIDR format (e.g., 192.168.1.0/24). If your kernel and iptables include iprange support, you may also specify ranges of ip addresses of the form lowaddress-highaddress No embedded white-space is allowed. Exclusion can appear after a list of addresses and/or address ranges. In that case, the final list of address is formed by taking the first list and then removing the addresses defined in the exclusion. Beginning in Shorewall 4.4.13, the second form of exclusion is allowed after all and any in the SOURCE and DEST columns of /etc/shorewall/rules. It allows you to omit arbitrary zones from the list generated by those key words. If you omit a sub-zone and there is an explicit or explicit CONTINUE policy, a connection to/from that zone can still be matched by the rule generated for a parent zone. For example:
/etc/shorewall/zones: #ZONE TYPE z1 ip z2:z1 ip ... /etc/shorewall/policy: #SOURCE DEST POLICY z1 net CONTINUE z2 net REJECT /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT all!z2 net tcp 22 In this case, SSH connections from z2 to net will be accepted by the generated z1 to net ACCEPT rule.
In most contexts, ipset names can be used as an address-or-range. Beginning with Shorewall 4.4.14, ipset lists enclosed in +[...] may also be included (see shorewall-ipsets (5)). The semantics of these lists when used in an exclusion are as follows: !+[set1,set2,...setN] produces a packet match if the packet does not match at least one of the sets. In other words, it is like NOT match set1 OR NOT match set2 ... OR NOT match setN. +[!set1,!set2,...!setN] produces a packet match if the packet does not match any of the sets. In other words, it is like NOT match set1 AND NOT match set2 ... AND NOT match setN.
Examples Example 1 - All IPv4 addresses except 192.168.3.4 !192.168.3.4 Example 2 - All IPv4 addresses except the network 192.168.1.0/24 and the host 10.2.3.4 !192.168.1.0/24,10.1.3.4 Example 3 - All IPv4 addresses except the range 192.168.1.3-192.168.1.12 and the network 10.0.0.0/8 !192.168.1.3-192.168.1.12,10.0.0.0/8 Example 4 - The network 192.168.1.0/24 except hosts 192.168.1.3 and 192.168.1.9 192.168.1.0/24!192.168.1.3,192.168.1.9 Example 5 - All parent zones except loc any!loc FILES /etc/shorewall/hosts /etc/shorewall/masq /etc/shorewall/rules /etc/shorewall/tcrules See ALSO shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tcinterfaces.xml0000644000175000017500000002061712222401136024207 0ustar teastepteastep shorewall-tcinterfaces 5 tcinterfaces Shorewall file /etc/shorewall/tcinterfaces Description This file lists the interfaces that are subject to simple traffic shaping. Simple traffic shaping is enabled by setting TC_ENABLED=Simple in shorewall.conf(5). A note on the bandwidth definition used in this file: don't use a space between the integer value and the unit: 30kbit is valid while 30 kbit is not. you can use one of the following units: kbps Kilobytes per second. mbps Megabytes per second. kbit Kilobits per second. mbit Megabits per second. bps or number Bytes per second. k or kb Kilo bytes. m or mb Megabytes. Only whole integers are allowed. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). INTERFACE The logical name of an interface. If you run both IPv4 and IPv6 Shorewall firewalls, a given interface should only be listed in one of the two configurations. TYPE - [external|internal] Optional. If given specifies whether the interface is external (facing toward the Internet) or internal (facing toward a local network) and enables SFQ flow classification. Simple traffic shaping is only useful on interfaces where queuing occurs. As a consequence, internal interfaces seldom benefit from simple traffic shaping. VPN interfaces are an exception because the encapsulated packets are later transferred over a slower external link. IN-BANDWIDTH (in_bandwidth) - {-|bandwidth[:burst]|~bandwidth[:interval:decay_interval]} The incoming bandwidth of that interface. Please note that you are not able to do traffic shaping on incoming traffic, as the traffic is already received before you could do so. But this allows you to define the maximum traffic allowed for this interface in total, if the rate is exceeded, the 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 to zero in which case Shorewall will not create an ingress qdisc.Must be set to zero if the REDIRECTED INTERFACES column is non-empty. The optional burst option was added in Shorewall 4.4.18. The default burst is 10kb. A larger burst can help make the bandwidth more accurate; often for fast lines, the enforced rate is well below the specified bandwidth. What is described above creates a rate/burst policing filter. Beginning with Shorewall 4.4.25, a rate-estimated policing filter may be configured instead. Rate-estimated filters should be used with Ethernet adapters that have Generic Receive Offload enabled by default. See Shorewall FAQ 97a. 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. OUT-BANDWIDTH (out_bandwidth) - [rate[:[burst][:[latency][:[peek][:[minburst]]]]]] Added in Shorewall 4.4.13. The terms are defined in tc-tbf(8). Shorewall provides defaults as follows: burst - 10kb latency - 200ms The remaining options are defaulted by tc(8). FILES /etc/shorewall/tcinterfaces. See ALSO http://ace-host.stuart.id.au/russell/files/tc/doc/sch_tbf.txt http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcpri(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-hosts.xml0000644000175000017500000002536312222401136022700 0ustar teastepteastep shorewall-hosts 5 hosts Shorewall file /etc/shorewall/hosts Description This file is used to define zones in terms of subnets and/or individual IP addresses. Most simple setups don't need to (should not) place anything in this file. The order of entries in this file is not significant in determining zone composition. Rather, the order that the zones are declared in shorewall-zones(5) determines the order in which the records in this file are interpreted. The only time that you need this file is when you have more than one zone connected through a single interface. If you have an entry for a zone and interface in shorewall-interfaces(5) then do not include any entries in this file for that same (zone, interface) pair. The columns in the file are as follows. ZONE - zone-name The name of a zone declared in shorewall-zones(5). You may not list the firewall zone in this column. HOST(S) - interface:{[{address-or-range[,address-or-range]...|+ipset|dynamic}[exclusion] The name of an interface defined in the shorewall-interfaces(5) file followed by a colon (":") and a comma-separated list whose elements are either: The IP address of a host. A network in CIDR format. An IP address range of the form low.address-high.address. Your kernel and iptables must have iprange match support. The name of an ipset. The word which makes the zone dynamic in that you can use the shorewall add and shorewall delete commands to change to composition of the zone.
You may also exclude certain hosts through use of an exclusion (see shorewall-exclusion(5).
OPTIONS (Optional) - [option[,option]...] A comma-separated list of options from the following list. The order in which you list the options is not significant but the list must have no embedded white-space. blacklist Check packets arriving on this port against the shorewall-blacklist(5) file. broadcast Used when you want to include limited broadcasts (destination IP address 255.255.255.255) from the firewall to this zone. Only necessary when: The network specified in the HOST(S) column does not include 255.255.255.255. The zone does not have an entry for this interface in shorewall-interfaces(5). destonly Normally used with the Multi-cast IP address range (224.0.0.0/4). Specifies that traffic will be sent to the specified net(s) but that no traffic will be received from the net(s). ipsec The zone is accessed via a kernel 2.6 ipsec SA. Note that if the zone named in the ZONE column is specified as an IPSEC zone in the shorewall-zones(5) file then you do NOT need to specify the 'ipsec' option here. maclist Connection requests from these hosts are compared against the contents of shorewall-maclist(5). If this option is specified, the interface must be an Ethernet NIC or equivalent and must be up before Shorewall is started. mss=mss Added in Shorewall 4.5.2. When present, causes the TCP mss for new connections to/from the hosts given in the HOST(S) column to be clamped at the specified mss. nosmurfs This option only makes sense for ports on a bridge. Filter packets for smurfs (packets with a broadcast address as the source). Smurfs will be optionally logged based on the setting of SMURF_LOG_LEVEL in shorewall.conf(5). After logging, the packets are dropped. routeback Shorewall should set up the infrastructure to pass packets from this/these address(es) back to themselves. This is necessary if hosts in this group use the services of a transparent proxy that is a member of the group or if DNAT is used to send requests originating from this group to a server in the group. tcpflags Packets arriving from these hosts are checked for certain illegal combinations of TCP flags. Packets found to have such a combination of flags are handled according to the setting of TCP_FLAGS_DISPOSITION after having been logged according to the setting of TCP_FLAGS_LOG_LEVEL.
Examples Example 1 The firewall runs a PPTP server which creates a ppp interface for each remote client. The clients are assigned IP addresses in the network 192.168.3.0/24 and in a zone named 'vpn'.#ZONE HOST(S) OPTIONS vpn ppp+:192.168.3.0/24 FILES /etc/shorewall/hosts See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-nesting(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tos.xml0000644000175000017500000001413512222401136022340 0ustar teastepteastep shorewall-tos 5 tos Shorewall Type of Service rules file /etc/shorewall/tos Description This file defines rules for setting Type Of Service (TOS). Its use is deprecated, beginning in Shorewall 4.5.1, in favor of the TOS target in shorewall-tcrules (5). The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). SOURCE - {all|address]|all:address|$FW} If all, may optionally be followed by ":" and an IP address, a MAC address, a subnet specification or the name of an interface. Example: all:192.168.2.3 MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 DEST - {all|address]|all:address} Example: 192.168.2.3 PROTOCOL (proto) - proto-name-or-number Protocol name or number. SOURCE PORT(S) (sport) - {-|port|lowport:highport} Source port or port range. If all ports, use "-". DEST PORT(S) (dport) - {-|port|lowport:highport} Destination port or port range. If all ports, use "-" TOS - tos Must may one of the following; tos-minimize-delay (16) tos-maximize-throughput (8) tos-maximize-reliability (4) tos-minimize-cost (2) tos-normal-service (0) To specify more than one flag, add their values together and specify the numeric result. MARK - [!]value[/mask][:C] If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. FILES /etc/shorewall/tos See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-tunnels.xml0000644000175000017500000003005012222401136023215 0ustar teastepteastep shorewall-tunnels 5 tunnels Shorewall VPN definition file /etc/shorewall/tunnels Description The tunnels file is used to define rules for encapsulated (usually encrypted) traffic to pass between the Shorewall system and a remote gateway. Traffic flowing through the tunnel is handled using the normal zone/policy/rule mechanism. See http://www.shorewall.net/VPNBasics.html for details. The columns in the file are as follows. TYPE - {ipsec[:{noah|ah}]|ipsecnat|ipip|gre|l2tp|pptpclient|pptpserver|[?]COMMENT|{openvpn|openvpnclient|openvpnserver}[:{tcp|udp}][:port]|generic:protocol[:port]} Types are as follows: 6to4 or 6in4 - 6to4 or 6in4 tunnel. The 6in4 synonym was added in 4.4.24. ipsec - IPv4 IPSEC ipsecnat - IPv4 IPSEC with NAT Traversal (UDP port 4500 encapsulation) ipip - IPv4 encapsulated in IPv4 (Protocol 4) gre - Generalized Routing Encapsulation (Protocol 47) l2tp - Layer 2 Tunneling Protocol (UDP port 1701) pptpclient - PPTP Client runs on the firewall pptpserver - PPTP Server runs on the firewall openvpn - OpenVPN in point-to-point mode openvpnclient - OpenVPN client runs on the firewall openvpnserver - OpenVPN server runs on the firewall generic - Other tunnel type If the type is ipsec, it may be followed by :ah to indicate that the Authentication Headers protocol (51) is used by the tunnel (the default is which means that protocol 51 is not used). NAT traversal is only supported with ESP (protocol 50) so ipsecnat tunnels don't allow the ah option (ipsecnat:noah may be specified but is redundant). If type is openvpn, openvpnclient or openvpnserver it may optionally be followed by ":" and tcp or udp to specify the protocol to be used. If not specified, udp is assumed. If type is openvpn, openvpnclient or openvpnserver it may optionally be followed by ":" and the port number used by the tunnel. if no ":" and port number are included, then the default port of 1194 will be used. . Where both the protocol and port are specified, the protocol must be given first (e.g., openvpn:tcp:4444). If type is generic, it must be followed by ":" and a protocol name (from /etc/protocols) or a protocol number. If the protocol is tcp or udp (6 or 17), then it may optionally be followed by ":" and a port number. Comments may be attached to Netfilter rules generated from entries in this file through the use of COMMENT lines. These lines begin with the word COMMENT; the remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word COMMENT. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. ZONE - zone The zone of the physical interface through which tunnel traffic passes. This is normally your internet zone. GATEWAY(S) (gateway or gateways) - address-or-range [ , ... ] The IP address of the remote tunnel gateway. If the remote gateway has no fixed address (Road Warrior) then specify the gateway as 0.0.0.0/0. May be specified as a network address and if your kernel and iptables include iprange match support then IP address ranges are also allowed. Beginning with Shorewall 4.5.3, a list of addresses or ranges may be given. Exclusion (shorewall-exclusion (5) ) is not supported. GATEWAY ZONES (gateway_zone or gateway_zones) - [zone[,zone]...] Optional. If the gateway system specified in the third column is a standalone host then this column should contain a comma-separated list of the names of the zones that the host might be in. This column only applies to IPSEC tunnels where it enables ISAKMP traffic to flow through the tunnel to the remote gateway(s). Example Example 1: IPSec tunnel. The remote gateway is 4.33.99.124 and the remote subnet is 192.168.9.0/24. The tunnel does not use the AH protocol #TYPE ZONE GATEWAY ipsec:noah net 4.33.99.124 Example 2: Road Warrior (LapTop that may connect from anywhere) where the "gw" zone is used to represent the remote LapTop #TYPE ZONE GATEWAY GATEWAY ZONES ipsec net 0.0.0.0/0 gw Example 3: Host 4.33.99.124 is a standalone system connected via an ipsec tunnel to the firewall system. The host is in zone gw. #TYPE ZONE GATEWAY GATEWAY ZONES ipsec net 4.33.99.124 gw Example 4: Road Warriors that may belong to zones vpn1, vpn2 or vpn3. The FreeS/Wan _updown script will add the host to the appropriate zone using the shorewall add command on connect and will remove the host from the zone at disconnect time. #TYPE ZONE GATEWAY GATEWAY ZONES ipsec net 0.0.0.0/0 vpn1,vpn2,vpn3 Example 5: You run the Linux PPTP client on your firewall and connect to server 192.0.2.221. #TYPE ZONE GATEWAY GATEWAY ZONES pptpclient net 192.0.2.221 Example 6: You run a PPTP server on your firewall. #TYPE ZONE GATEWAY GATEWAY ZONES pptpserver net 0.0.0.0/0 Example 7: OPENVPN tunnel. The remote gateway is 4.33.99.124 and openvpn uses port 7777. #TYPE ZONE GATEWAY GATEWAY ZONES openvpn:7777 net 4.33.99.124 Example 8: You have a tunnel that is not one of the supported types. Your tunnel uses UDP port 4444. The other end of the tunnel is 4.3.99.124. #TYPE ZONE GATEWAY GATEWAY ZONES generic:udp:4444 net 4.3.99.124 FILES /etc/shorewall/tunnels See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-lite.conf.xml0000644000175000017500000001625112222401136023415 0ustar teastepteastep shorewall-lite.conf 5 shorewall-lite.conf Shorewall Lite global configuration file /etc/shorewall-lite/shorewall-lite.conf Description This file sets options that apply to Shorewall Lite as a whole. The file consists of Shell comments (lines beginning with '#'), blank lines and assignment statements (variable=value). Each variable's setting is preceded by comments that describe the variable and it's effect. Any option not specified in this file gets its value from the shorewall.conf file used during compilation of /var/lib/shorewall-lite/firewall. Those settings may be found in the file /var/lib/shorewall-lite/firewall.conf. OPTIONS The following options may be set in shorewall.conf. IPTABLES=[pathname] This parameter names the iptables executable to be used by Shorewall. If not specified or if specified as a null value, then the iptables executable located using the PATH option is used. LOGFILE=[pathname] This parameter tells the /sbin/shorewall program where to look for Shorewall messages when processing the dump, logwatch, show log, and hits commands. If not assigned or if assigned an empty value, /var/log/messages is assumed. LOGFORMAT=["formattemplate"] The value of this variable generate the --log-prefix setting for Shorewall logging rules. It contains a “printf” formatting template which accepts three arguments (the chain name, logging rule number (optional) and the disposition). To use LOGFORMAT with fireparse, set it as: LOGFORMAT="fp=%s:%d a=%s " If the LOGFORMAT value contains the substring “%d” then the logging rule number is calculated and formatted in that position; if that substring is not included then the rule number is not included. If not supplied or supplied as empty (LOGFORMAT="") then “Shorewall:%s:%s:” is assumed. PATH=pathname[:pathname]... Determines the order in which Shorewall searches directories for executable files. RESTOREFILE=[filename] Specifies the simple name of a file in /var/lib/shorewall to be used as the default restore script in the shorewall save, shorewall restore, shorewall forget and shorewall -f start commands. SHOREWALL_SHELL=[pathname] This option is used to specify the shell program to be used to run the Shorewall compiler and to interpret the compiled script. If not specified or specified as a null value, /bin/sh is assumed. Using a light-weight shell such as ash or dash can significantly improve performance. SUBSYSLOCK=[pathname] This parameter should be set to the name of a file that the firewall should create if it starts successfully and remove when it stops. Creating and removing this file allows Shorewall to work with your distribution's initscripts. For RedHat, this should be set to /var/lock/subsys/shorewall. For Debian, the value is /var/state/shorewall and in LEAF it is /var/run/shorewall. VERBOSITY=[number] Shorewall has traditionally been very noisy (produced lots of output). You may set the default level of verbosity using the VERBOSITY OPTION. Values are: 0 - Silent. You may make it more verbose using the -v option 1 - Major progress messages displayed 2 - All progress messages displayed (old default behavior) If not specified, then 2 is assumed. FILES /etc/shorewall-lite/shorewall.conf See ALSO http://www.shorewall.net/Documentation_Index.html shorewall-lite(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall-interfaces(5), shorewall-ipsec(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-route_rules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-providers.xml0000644000175000017500000004321612222401136023552 0ustar teastepteastep shorewall-providers 5 providers Shorewall Providers file /etc/shorewall/providers Description This file is used to define additional routing tables. You will want to define an additional table if: You have connections to more than one ISP or multiple connections to the same ISP You run Squid as a transparent proxy on a host other than the firewall. You have other requirements for policy routing. Each entry in the file defines a single routing table. If you wish to omit a column entry but want to include an entry in the next column, use "-" for the omitted entry. The columns in the file are as follows. NAME - name The provider name. Must be a valid shell variable name. The names 'local', 'main', 'default' and 'unspec' are reserved and may not be used as provider names. NUMBER - number The provider number -- a number between 1 and 15. Each provider must be assigned a unique value. MARK (Optional) - value A FWMARK value used in your shorewall-tcrules(5) file to direct packets to this provider. If HIGH_ROUTE_MARKS=Yes in shorewall.conf(5), then the value must be a multiple of 256 between 256 and 65280 or their hexadecimal equivalents (0x0100 and 0xff00 with the low-order byte of the value being zero). Otherwise, the value must be between 1 and 255. Each provider must be assigned a unique mark value. This column may be omitted if you don't use packet marking to direct connections to a particular provider. DUPLICATE - routing-table-name The name of an existing table to duplicate to create this routing table. May be or the name of a previously listed provider. You may select only certain entries from the table to copy by using the COPY column below. This column should contain a dash ("-') when USE_DEFAULT_RT=Yes in shorewall.conf(5). INTERFACE - interface[:address] The name of the network interface to the provider. Must be listed in shorewall-interfaces(5). In general, that interface should not have the option specified unless is given in the OPTIONS column of this entry. Where more than one provider is serviced through a single interface, the interface must be followed by a colon and the IP address of the interface that is supplied by the associated provider. GATEWAY - {-|address|detect} The IP address of the provider's gateway router. You can enter "detect" here and Shorewall will attempt to detect the gateway automatically. For PPP devices, you may omit this column. OPTIONS (Optional) - [-|option[,option]...] A comma-separated list selected from the following. The order of the options is not significant but the list may contain no embedded white-space. autosrc Added in Shorewall 4.5.17. Causes a host route to the provider's gateway router to be added to the provider's routing table. This is the default behavior unless overridden by a following noautosrc option. track If specified, inbound connections on this interface are to be tracked so that responses may be routed back out this same interface. You want to specify if internet hosts will be connecting to local servers through this provider. Beginning with Shorewall 4.4.3, defaults to the setting of the TRACK_PROVIDERS option in shorewall.conf (5). If you set TRACK_PROVIDERS=Yes and want to override that setting for an individual provider, then specify (see below). balance[=weight] The providers that have specified will get outbound traffic load-balanced among them. By default, all interfaces with specified will have the same weight (1). You can change the weight of an interface by specifying weight where weight is the weight of the route out of this interface. loose Shorewall normally adds a routing rule for each IP address on an interface which forces traffic whose source is that IP address to be sent using the routing table for that interface. Setting prevents creation of such rules on this interface. noautosrc Added in Shorewall 4.5.17. Prevents the addition of a host route to the provider's gateway router from being added to the provider's routing table. This option must be used with caution as it can cause start and restart failures. notrack Added in Shorewall 4.4.3. When specified, turns off . optional (deprecated for use with providers that do not share an interface) If the interface named in the INTERFACE column is not up and configured with an IPv4 address then ignore this provider. If not specified, the value of the option for the INTERFACE in shorewall-interfaces(5) is assumed. Use of that option is preferred to this one, unless an address is provider in the INTERFACE column. src=source-address Specifies the source address to use when routing to this provider and none is known (the local client has bound to the 0 address). May not be specified when an address is given in the INTERFACE column. If this option is not used, Shorewall substitutes the primary IP address on the interface named in the INTERFACE column. mtu=number Specifies the MTU when forwarding through this provider. If not given, the MTU of the interface named in the INTERFACE column is assumed. fallback[=weight] Indicates that a default route through the provider should be added to the default routing table (table 253). If a weight is given, a balanced route is added with the weight of this provider equal to the specified weight. If the option is given without a weight, an separate default route is added through the provider's gateway; the route has a metric equal to the provider's NUMBER. Prior to Shorewall 4.4.24, the option is ignored with a warning message if USE_DEFAULT_RT=Yes in shorewall.conf. tproxy Added in Shorewall 4.5.4. Used for supporting the TPROXY action in shorewall-tcrules(5). See http://www.shorewall.net/Shorewall_Squid_Usage.html. When specified, the MARK, DUPLICATE and GATEWAY columns should be empty, INTERFACE should be set to 'lo' and should be the only OPTION. Only one provider is allowed. hostroute Added in Shorewall 4.5.21. This is the default behavior that results in a host route to the defined GATEWAY being inserted into the main routing table and into the provider's routing table. hostroute is required for older distributions but nohostroute (below) is appropriate for recent distributions. hostroute may interfere with Zebra's ability to add routes on some distributions such as Debian 7. nohostroute Added in Shorewall 4.5.21. nohostroute inhibits addition of a host route to the defined GATEWAY being inserted into the main routing table and into the provider's routing table. nohostroute is not appropriate for older distributions but is appropriate for recent distributions. nohostroute allows Zebra's to correctly add routes on some distributions such as Debian 7. COPY - [{|interface[,interface]...}] A comma-separated list of other interfaces on your firewall. Wildcards specified using an asterisk ("*") are permitted (e.g., tun* ). Usually used only when DUPLICATE is . Only copy routes through INTERFACE and through interfaces listed here. If you only wish to copy routes through INTERFACE, enter in this column. Beginning with Shorewall 4.5.17, blackhole, unreachable and prohibit routes are no longer copied by default but may be copied by including blackhole,unreachable and prohibit respectively in the COPY list. Examples Example 1: You run squid in your DMZ on IP address 192.168.2.99. Your DMZ interface is eth2 #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS Squid 1 1 - eth2 192.168.2.99 - Example 2: eth0 connects to ISP 1. The IP address of eth0 is 206.124.146.176 and the ISP's gateway router has IP address 206.124.146.254. eth1 connects to ISP 2. The IP address of eth1 is 130.252.99.27 and the ISP's gateway router has IP address 130.252.99.254. eth2 connects to a local network. #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY ISP1 1 1 main eth0 206.124.146.254 track,balance eth2 ISP2 2 2 main eth1 130.252.99.254 track,balance eth2 FILES /etc/shorewall/providers See ALSO http://shorewall.net/MultiISP.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-rtrules.xml0000644000175000017500000001603512222401136023234 0ustar teastepteastep shorewall-rtrules 5 rtrules Shorewall Routing Rules file /etc/shorewall/rtrules Description Entries in this file cause traffic to be routed to one of the providers listed in shorewall-providers(5). The columns in the file are as follows. SOURCE (Optional) - {-|[&]interface|address|interface:address} An ip address (network or host) that matches the source IP address in a packet. May also be specified as an interface name optionally followed by ":" and an address. If the device lo is specified, the packet must originate from the firewall itself. Beginning with Shorewall 4.5.0, you may specify &interface in this column to indicate that the source is the primary IP address of the named interface. DEST (Optional) - {-|address} An ip address (network or host) that matches the destination IP address in a packet. If you choose to omit either SOURCE or DEST, place "-" in that column. Note that you may not omit both SOURCE and DEST. PROVIDER - {provider-name|provider-number|main} The provider to route the traffic through. May be expressed either as the provider name or the provider number. May also be main or 254 for the main routing table. This can be used in combination with VPN tunnels, see example 2 below. PRIORITY - priority The rule's numeric priority which determines the order in which the rules are processed. Rules with equal priority are applied in the order in which they appear in the file. 1000-1999 Before Shorewall-generated 'MARK' rules 11000-11999 After 'MARK' rules but before Shorewall-generated rules for ISP interfaces. 26000-26999 After ISP interface rules but before 'default' rule. MARK - {-|mark[/mask]} Optional -- added in Shorewall 4.4.25. For this rule to be applied to a packet, the packet's mark value must match the mark when logically anded with the mask. If a mask is not supplied, Shorewall supplies a suitable provider mask. Examples Example 1: You want all traffic coming in on eth1 to be routed to the ISP1 provider. #SOURCE DEST PROVIDER PRIORITY MASK eth1 - ISP1 1000 Example 2: You use OpenVPN (routed setup /tunX) in combination with multiple providers. In this case you have to set up a rule to ensure that the OpenVPN traffic is routed back through the tunX interface(s) rather than through any of the providers. 10.8.0.0/24 is the subnet chosen in your OpenVPN configuration (server 10.8.0.0 255.255.255.0). #SOURCE DEST PROVIDER PRIORITY MASK - 10.8.0.0/24 main 1000 FILES /etc/shorewall/rtrules See ALSO http://shorewall.net/MultiISP.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-netmap.xml0000644000175000017500000001773312222401136023026 0ustar teastepteastep shorewall-netmap 5 netmap Shorewall NETMAP definition file /etc/shorewall/netmap Description This file is used to map addresses in one network to corresponding addresses in a second network. To use this file, your kernel and iptables must have NETMAP support included. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). TYPE - {DNAT|SNAT}[:{P|O|T}] Must be DNAT or SNAT; beginning with Shorewall 4.4.23, may be optionally followed by :P, :O or :T to perform stateless NAT. Stateless NAT requires Rawpost Table support in your kernel and iptables (see the output of shorewall show capabilities). If DNAT or DNAT:P, traffic entering INTERFACE and addressed to NET1 has its destination address rewritten to the corresponding address in NET2. If SNAT or SNAT:T, traffic leaving INTERFACE with a source address in NET1 has it's source address rewritten to the corresponding address in NET2. If DNAT:O, traffic originating on the firewall and leaving via INTERFACE and addressed to NET1 has its destination address rewritten to the corresponding address in NET2. If DNAT:P, traffic entering via INTERFACE and addressed to NET1 has its destination address rewritten to the corresponding address in NET2. If SNAT:P, traffic entering via INTERFACE with a destination address in NET1 has it's source address rewritten to the corresponding address in NET2. If SNAT:O, traffic originating on the firewall and leaving via INTERFACE with a source address in NET1 has it's source address rewritten to the corresponding address in NET2. NET1 - network-address Network in CIDR format (e.g., 192.168.1.0/24). Beginning with Shorewall 4.4.24, exclusion is supported. INTERFACE - interface The name of a network interface. The interface must be defined in shorewall-interfaces(5). Shorewall allows loose matches to wildcard entries in shorewall-interfaces(5). For example, ppp0 in this file will match a shorewall-interfaces(8) entry that defines ppp+. NET2 - network-address Network in CIDR format NET3 (Optional) - network-address Added in Shorewall 4.4.11. If specified, qualifies INTERFACE. It specifies a SOURCE network for DNAT rules and a DESTINATION network for SNAT rules. PROTO - protocol-number-or-name Optional -- added in Shorewall 4.4.23.2. Only packets specifying this protocol will have their IP header modified. DEST PORT(S) (dport) - port-number-or-name-list Optional - added in Shorewall 4.4.23.2. Destination Ports. A comma-separated list of Port names (from services(5)), port numbers or port ranges; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). ICMP types may be specified as a numeric type, a numeric type and code separated by a slash (e.g., 3/4), or a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP. If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example bit for bit-torrent). If no PORT is given, ipp2p is assumed. An entry in this field requires that the PROTO column specify icmp (1), tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following field is supplied. SOURCE PORT(S) (sport) - port-number-or-name-list Optional -- added in Shorewall 4.4.23.2. Source port(s). If omitted, any source port is acceptable. Specified as a comma-separated list of port names, port numbers or port ranges. An entry in this field requires that the PROTO column specify tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following fields is supplied. FILES /etc/shorewall/netmap See ALSO http://shorewall.net/netmap.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-nat.xml0000644000175000017500000001403212222401136022311 0ustar teastepteastep shorewall-nat 5 nat Shorewall one-to-one NAT file /etc/shorewall/nat Description This file is used to define one-to-one Network Address Translation (NAT). If all you want to do is simple port forwarding, do NOT use this file. See http://www.shorewall.net/FAQ.htm#faq1. Also, in many cases, Proxy ARP (shorewall-proxyarp(5)) is a better solution that one-to-one NAT. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). EXTERNAL - {address|[?]COMMENT} External IP Address - this should NOT be the primary IP address of the interface named in the next column and must not be a DNS Name. If you put COMMENT in this column, the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries in the file. The comment will appear delimited by "/* ... */" in the output of "shorewall show nat" To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. INTERFACE - interfacelist[:[digit]] Interfaces that have the EXTERNAL address. If ADD_IP_ALIASES=Yes in shorewall.conf(5), Shorewall will automatically add the EXTERNAL address to this interface. Also if ADD_IP_ALIASES=Yes, you may follow the interface name with ":" and a digit to indicate that you want Shorewall to add the alias with this name (e.g., "eth0:0"). That allows you to see the alias with ifconfig. That is the only thing that this name is good for -- you cannot use it anywhere else in your Shorewall configuration. Each interface must match an entry in shorewall-interfaces(5). Shorewall allows loose matches to wildcard entries in shorewall-interfaces(5). For example, ppp0 in this file will match a shorewall-interfaces(5) entry that defines ppp+. If you want to override ADD_IP_ALIASES=Yes for a particular entry, follow the interface name with ":" and no digit (e.g., "eth0:"). INTERNAL - address Internal Address (must not be a DNS Name). ALL INTERFACES (allints) - [Yes|No] If Yes or yes, NAT will be effective from all hosts. If No or no (or left empty) then NAT will be effective only through the interface named in the INTERFACE column. LOCAL - [Yes|No] If Yes or yes, NAT will be effective from the firewall system FILES /etc/shorewall/nat See ALSO http://shorewall.net/NAT.htm http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-policy.xml0000644000175000017500000003243212222401136023032 0ustar teastepteastep shorewall-policy 5 policy Shorewall policy file /etc/shorewall/policy Description This file defines the high-level policy for connections between zones defined in shorewall-zones(5). The order of entries in this file is important This file determines what to do with a new connection request if we don't get a match from the /etc/shorewall/rules file . For each source/destination pair, the file is processed in order until a match is found ("all" will match any client or server). Intra-zone policies are pre-defined For $FW and for all of the zones defined in /etc/shorewall/zones, the POLICY for connections from the zone to itself is ACCEPT (with no logging or TCP connection rate limiting) but may be overridden by an entry in this file. The overriding entry must be explicit (specifying the zone name in both SOURCE and DEST) or it must use "all+" (Shorewall 4.5.17 or later). Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall.conf, then the implicit policy to/from any sub-zone is CONTINUE. These implicit CONTINUE policies may also be overridden by an explicit entry in this file. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). SOURCE - zone|$FW|all|all+ Source zone. Must be the name of a zone defined in shorewall-zones(5), $FW, "all" or "all+". Support for "all+" was added in Shorewall 4.5.17. "all" does not override the implicit intra-zone ACCEPT policy while "all+" does. DEST - zone|$FW|all|all+ Destination zone. Must be the name of a zone defined in shorewall-zones(5), $FW, "all" or "all+". If the DEST is a bport zone, then the SOURCE must be "all", "all+", another bport zone associated with the same bridge, or it must be an ipv4 zone that is associated with only the same bridge. Support for "all+" was added in Shorewall 4.5.17. "all" does not override the implicit intra-zone ACCEPT policy while "all+" does. POLICY - {ACCEPT|DROP|REJECT|CONTINUE|QUEUE|NFQUEUE[(queuenumber)]|NONE}[:{default-action-or-macro[:level]|None}] Policy if no match from the rules file is found. If the policy is neither CONTINUE nor NONE then the policy may be followed by ":" and one of the following: The word "None" or "none". This causes any default action defined in shorewall.conf(5) to be omitted for this policy. The name of an action. The action will be invoked before the policy is enforced. Actions can have parameters specified. Beginning with Shorewall 4.5.10, the action name can be followed optionally by a colon and a log level. The level will be applied to each rule in the action or body that does not already have a log level. Possible actions are: ACCEPT Accept the connection. DROP Ignore the connection request. REJECT For TCP, send RST. For all other, send an "unreachable" ICMP. QUEUE Queue the request for a user-space application such as Snort-inline. NFQUEUE Queue the request for a user-space application using the nfnetlink_queue mechanism. If a queuenumber is not given, queue zero (0) is assumed. CONTINUE Pass the connection request past any other rules that it might also match (where the source or destination zone in those rules is a superset of the SOURCE or DEST in this policy). See shorewall-nesting(5) for additional information. NONE Assume that there will never be any packets from this SOURCE to this DEST. Shorewall will not create any infrastructure to handle such packets and you may not have any rules with this SOURCE and DEST in the /etc/shorewall/rules file. If such a packet is received, the result is undefined. NONE may not be used if the SOURCE or DEST columns contain the firewall zone ($FW) or "all". LOG LEVEL (loglevel) - [log-level|ULOG|NFLOG] Optional - if supplied, each connection handled under the default POLICY is logged at that level. If not supplied, no log message is generated. See syslog.conf(5) for a description of log levels. You may also specify ULOG or NFLOG (must be in upper case). This will log to the ULOG or NFLOG target and will send to a separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html). If you don't want to log but need to specify the following column, place "-" here. BURST:LIMIT (limit) - [{s|d}:[[name]:]]]rate/{second|minute}[:burst] If passed, specifies the maximum TCP connection rate and the size of an acceptable burst. If not specified, TCP connections are not limited. If the burst parameter is omitted, a value of 5 is assumed. When or is specified, the rate applies per source IP address or per destination IP address respectively. The name may be chosen by the user and specifies a hash table to be used to count matching connections. If not give, the name shorewall is assumed. Where more than one POLICY specifies the same name, the connections counts for the policies are aggregated and the individual rates apply to the aggregated count. CONNLIMIT - limit[:mask] May be used to limit the number of simultaneous connections from each individual host to limit connections. While the limit is only checked on connections to which this policy could apply, the number of current connections is calculated over all current connections from the SOURCE host. By default, the limit is applied to each host individually but can be made to apply to networks of hosts by specifying a mask. The mask specifies the width of a VLSM mask to be applied to the source address; the number of current connections is then taken over all hosts in the subnet source-address/mask. Example All connections from the local network to the internet are allowed All connections from the internet are ignored but logged at syslog level KERNEL.INFO. All other connection requests are rejected and logged at level KERNEL.INFO. #SOURCE DEST POLICY LOG BURST:LIMIT # LEVEL loc net ACCEPT net all DROP info # # THE FOLLOWING POLICY MUST BE LAST # all all REJECT info FILES /etc/shorewall/policy See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-vardir.xml0000644000175000017500000000412712222401136023022 0ustar teastepteastep shorewall-vardir 5 vardir Shorewall file /etc/shorewall/vardir Description This file does not exist by default. You may create the file if you want to change the directory used by Shorewall to store state information, including compiled firewall scripts. By default, the directory used is /var/lib/shorewall/. The file contains a single variable assignment: directory where directory is the name of a directory. If you add this file, you should copy the files from /var/lib/shorewall to the new directory before performing a shorewall restart. Example VARDIR=/root/shorewall FILES /etc/shorewall/vardir See ALSO shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-routes.xml0000644000175000017500000000713612222401136023057 0ustar teastepteastep shorewall-routes 5 routes Shorewall file /etc/shorewall/routes Description This file was added in Shorewall 4.4.15 and is used to define routes to be added to provider routing tables. The columns in the file are as follows. PROVIDER The name or number of a provider defined in shorewall-providers (5). Beginning with Shorewall 4.5.14, you may also enter in this column to add routes to the main routing table. DEST Destination host address or network address. GATEWAY (Optional) If specified, gives the IP address of the gateway to the DEST. Beginning with Shorewall 4.5.14, you may specify in this column to create a blackhole route. Beginning with Shorewall 4.5.15, you may specify or in this column to create a prohibit or unreachable route respectively. DEVICE (Optional) Specifies the device route. If neither DEVICE nor GATEWAY is given, then the INTERFACE specified for the PROVIDER in shorewall-providers (5). This column must be omitted if , or is specified in the GATEWAY column. FILES /etc/shorewall/routes See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-lite-vardir.xml0000644000175000017500000000575312222401136023763 0ustar teastepteastep shorewall-lite-vardir 5 vardir Shorewall Lite file /etc/shorewall-lite/vardir Description This file does not exist by default. You may create the file if you want to change the directory used by Shorewall Lite to store state information, including compiled firewall scripts. By default, the directory used is /var/lib/shorewall-lite/. The file contains a single variable assignment: directory where directory is the name of a directory. If you add this file, you should copy the files from /var/lib/shorewall-lite to the new directory before performing a shorewall-lite restart. Beginning with Shorewall 4.5.2, use of this file is deprecated in favor of specifying VARDIR in the shorewallrc file used during installation of Shorewall Core. While the name of the variable remains VARDIR, the meaning is slightly different. When set in shorewallrc, Shorewall Lite, will create a directory under the specified path name to hold state information. Example:
VARDIR=/opt/var/lib/ The state directory for Shorewall Lite will be /opt/var/lib/shorewall-lite/.
When VARDIR is set in /etc/shorewall-lite/vardir, Shorewall Lite will save its state in the directory specified.
Example VARDIR=/root/shorewall FILES /etc/shorewall-lite/vardir See ALSO shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall-interfaces(5), shorewall-ipsec(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-route_rules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tcpri.xml0000644000175000017500000001505412222401136022655 0ustar teastepteastep shorewall-tcpri 5 tcpri Shorewall file /etc/shorewall/tcpri Description This file is used to specify the priority of traffic for simple traffic shaping (TC_ENABLED=Simple in shorewall.conf(5)). The priority band of each packet is determined by the last entry that the packet matches. If a packet doesn't match any entry in this file, then its priority will be determined by its TOS field. The default mapping is as follows but can be changed by setting the TC_PRIOMAP option in shorewall.conf(5). TOS Bits Means Linux Priority BAND ------------------------------------------------------------ 0x0 0 Normal Service 0 Best Effort 2 0x2 1 Minimize Monetary Cost 1 Filler 3 0x4 2 Maximize Reliability 0 Best Effort 2 0x6 3 mmc+mr 0 Best Effort 2 0x8 4 Maximize Throughput 2 Bulk 3 0xa 5 mmc+mt 2 Bulk 3 0xc 6 mr+mt 2 Bulk 3 0xe 7 mmc+mr+mt 2 Bulk 3 0x10 8 Minimize Delay 6 Interactive 1 0x12 9 mmc+md 6 Interactive 1 0x14 10 mr+md 6 Interactive 1 0x16 11 mmc+mr+md 6 Interactive 1 0x18 12 mt+md 4 Int. Bulk 2 0x1a 13 mmc+mt+md 4 Int. Bulk 2 0x1c 14 mr+mt+md 4 Int. Bulk 2 0x1e 15 mmc+mr+mt+md 4 Int. Bulk 2 The columns in the file are as follows. BAND - {1|2|3} Classifies matching traffic as High Priority (1), Medium Priority (2) or Low Priority (3). For those interfaces listed in shorewall-tcinterfaces(5), Priority 2 traffic will be deferred so long and there is Priority 1 traffic queued and Priority 3 traffic will be deferred so long as there is Priority 1 or Priority 2 traffic to send. PROTO - protocol[,...] Optional. The name or number of an IPv4 protocol. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. PORT(S) - port [,...] Optional. May only be given if the the PROTO is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136). A list of one or more port numbers or service names from /etc/services. Port ranges of the form lowport:highport may also be included. ADDRESS - [address] Optional. The IP or MAC address that the traffic originated from. MAC addresses must be given in Shorewall format. If this column contains an address, then the PROTO, PORT(S) and INTERFACE column must be empty ("-"). INTERFACE - [interface] Optional. The logical name of an interface that traffic arrives from. If given, the PROTO, PORT(S) and ADDRESS columns must be empty ("-"). INTERFACE classification of packets occurs before classification by PROTO/PORT(S)/ADDRESS. So it is highly recommended to place entries that specify INTERFACE at the top of the file so that the rule about last entry matches is preserved. HELPER - [helper] Optional. Names a Netfilter protocol helper module such as ftp, sip, amanda, etc. A packet will match if it was accepted by the named helper module. You can also append "-" and a port number to the helper module name (e.g., ftp-21) to specify the port number that the original connection was made on. FILES /etc/shorewall/tcpri See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs prio(8), shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-tcrules.xml0000644000175000017500000015510512222401136023217 0ustar teastepteastep shorewall-tcrules 5 tcrules Shorewall Packet Marking rules file /etc/shorewall/tcrules Description Entries in this file cause packets to be marked as a means of classifying them for traffic control or policy routing. 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. If you use multiple internet providers with the 'track' option, in /etc/shorewall/providers be sure to read the restrictions at http://shorewall.net/MultiISP.html. Beginning with Shorewall 4.5.4, the tcrules file supports two different formats: FORMAT 1 (default - deprecated) The older limited-function version of TPROXY is supported. FORMAT 2 The newer version of TPROXY is supported. The format is specified by a line as follows:
[?]FORMAT {1|2}
The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is the preferred form; the form without the '?' is deprecated. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ACTION (mark) - mark Where mark may assume one of the following values. A mark value which is an integer in the range 1-255. Normally will set the mark value. If preceded by a vertical bar ("|"), the mark value will be logically ORed with the current mark value to produce a new mark value. If preceded by an ampersand ("&"), will be logically ANDed with the current mark value to produce a new mark value. Both "|" and "&" require Extended MARK Target support in your kernel and iptables; neither may be used with connection marks (see below). May optionally be followed by :P, :F,:T or :I where :P indicates that marking should occur in the PREROUTING chain, :F indicates that marking should occur in the FORWARD chain, :I indicates that marking should occur in the INPUT chain (added in Shorewall 4.4.13), and :T indicates that marking should occur in the POSTROUTING chain. If neither :P, :F nor :T follow the mark value then the chain is determined as follows: - If the SOURCE is $FW[:address-or-range[,address-or-range]...], then the rule is inserted into the OUTPUT chain. When HIGH_ROUTE_MARKS=Yes, 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 chain (see below). - Otherwise, the chain is determined by the setting of MARK_IN_FORWARD_CHAIN in shorewall.conf(5). Please note that :I is included for completeness and affects neither traffic shaping nor policy routing. If your kernel and iptables include CONNMARK support then you can also mark the connection rather than the packet. The mark value may be optionally followed by "/" and a mask value (used to determine those bits of the connection mark to actually be set). When a mask is specified, the result of logically ANDing the mark value with the mask must be the same as the mark value. The mark and optional mask are then followed by one of: C Mark the connection in the chain determined by the setting of MARK_IN_FORWARD_CHAIN CF Mark the connection in the FORWARD chain CP Mark the connection in the PREROUTING chain. CT Mark the connection in the POSTROUTING chain CI Mark the connection in the INPUT chain. This option is included for completeness and has no applicability to traffic shaping or policy routing. A mark range which is a pair of integers separated by a dash ("-"). Added in Shorewall 4.5.9. May be optionally followed by a slash ("/") and a mask and requires the Statistics Match capability in iptables and kernel. Marks in the specified range are assigned to packets on a round-robin fashion. When a mask is specified, the result of logically ANDing each mark value with the mask must be the same as the mark value. The least significant bit in the mask is used as an increment. For example, if '0x200-0x400/0xff00' is specified, then the assigned mark values are 0x200, 0x300 and 0x400 in equal proportions. If no mask is specified, then ( 2 ** MASK_BITS ) - 1 is assumed (MASK_BITS is set in shorewall.conf(5)). May optionally be followed by :P, :F,:T or :I where :P indicates that marking should occur in the PREROUTING chain, :F indicates that marking should occur in the FORWARD chain, :I indicates that marking should occur in the INPUT chain (added in Shorewall 4.4.13), and :T indicates that marking should occur in the POSTROUTING chain. If neither :P, :F nor :T follow the mark value then the chain is determined as follows: - If the SOURCE is $FW[:address-or-range[,address-or-range]...], then the rule is inserted into the OUTPUT chain. When HIGH_ROUTE_MARKS=Yes, 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 chain (see below). - Otherwise, the chain is determined by the setting of MARK_IN_FORWARD_CHAIN in shorewall.conf(5). Please note that :I is included for completeness and affects neither traffic shaping nor policy routing. If your kernel and iptables include CONNMARK support then you can also mark the connection rather than the packet. The mark range and optional mask can then followed by one of: C Mark the connection in the chain determined by the setting of MARK_IN_FORWARD_CHAIN CF Mark the connection in the FORWARD chain CP Mark the connection in the PREROUTING chain. CT Mark the connection in the POSTROUTING chain CI Mark the connection in the INPUT chain. This option is included for completeness and has no applicability to traffic shaping or policy routing. A classification Id (classid) of the form major:minor where major and minor are integers. Corresponds to the 'class' specification in these traffic shaping modules: atm cbq dsmark pfifo_fast htb prio Classification occurs in the POSTROUTING chain except when the SOURCE is $FW[:address] in which case classification occurs in the OUTPUT chain. When using Shorewall's built-in traffic shaping tool, the major class is the device number (the first device in shorewall-tcdevices(5) is major class 1, the second device is major class 2, and so on) and the minor class is the class's MARK value in shorewall-tcclasses(5) preceded by the number 1 (MARK 1 corresponds to minor class 11, MARK 5 corresponds to minor class 15, MARK 22 corresponds to minor class 122, etc.). Beginning with Shorewall 4.4.27, the classid may be optionally followed by ':' and a capital letter designating the chain where classification is to occur. F FORWARD chain. T POSTROUTING chain (default). CHECKSUM Added in Shorewall 4.5.9. Compute and fill in the checksum in a packet that lacks a checksum. This is particularly useful if you need to work around old applications, such as dhcp clients, that do not work well with checksum offloads, but you don't want to disable checksum offload in your device. Requires 'Checksum Target' support in your kernel and iptables. [?]COMMENT -- the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries. The comment will appear delimited by "/* ... */" in the output of shorewall show mangle To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. CONTINUE Don't process any more marking rules ‒in the table. As in 1) above, may be followed by :P or :F. Currently, CONTINUE may not be used with exclusion (see the SOURCE and DEST columns below); that restriction will be removed when iptables/Netfilter provides the necessary support. DIVERT Added in Shorewall 4.5.4 and only available when FORMAT is 2. Two DIVERT rule should precede the TPROXY rule and should select DEST PORT tcp 80 and SOURCE PORT tcp 80 respectively (assuming that tcp port 80 is being proxied). DIVERT avoids sending packets to the TPROXY target once a socket connection to Squid3 has been established by TPROXY. DIVERT marks the packet with a unique mark and exempts it from any rules that follow. DSCP(dscp) Added in Shorewall 4.5.1. Sets the Differentiated Services Code Point field in the IP header. The dscp value may be given as an even number (hex or decimal) or as the name of a DSCP class. Valid class names and their associated hex numeric values are: CS0 => 0x00 CS1 => 0x08 CS2 => 0x10 CS3 => 0x18 CS4 => 0x20 CS5 => 0x28 CS6 => 0x30 CS7 => 0x38 BE => 0x00 AF11 => 0x0a AF12 => 0x0c AF13 => 0x0e AF21 => 0x12 AF22 => 0x14 AF23 => 0x16 AF31 => 0x1a AF32 => 0x1c AF33 => 0x1e AF41 => 0x22 AF42 => 0x24 AF43 => 0x26 EF => 0x2e To indicate more than one class, add their hex values together and specify the result. May be optionally followed by ':' and a capital letter designating the chain where classification is to occur. F FORWARD chain. T POSTROUTING chain (default). IMQ(number) Added in Shorewall 4.5.1. Specifies that the packet should be passed to the IMQ identified by number. Requires IMQ Target support in your kernel and iptables. IPMARK ‒ 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. 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 to the right by shift bits. The result is then LANDed with mask1 then LORed with mask2. 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:
[([{|}][,[mask1][,[mask2][,[shift]]]])]
Default values are: mask1 = 0xFF mask2 = 0x00 shift = 0 and 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) Suppose that the source IP address is 192.168.4.3 = 0xc0a80403; then 0xc0a80403 >> 0 = 0xc0a80403 0xc0a80403 LAND 0xFF = 0x03 0x03 LOR 0x0x10100 = 0x10103 or 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 values must be unique. That is, the same numeric value cannot be used as both a major and a minor number for the same interface unless class nesting occurs (which is not currently possible with Shorewall). You should 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 an invalid class ID since the major and minor classes are equal. So you might choose instead to use IPMARK(src,0xFF,0x10100) as in the example above so that all of your minor classes will have a value > 256.
RESTORE[/mask] -- restore the packet's mark from the connection's mark using the supplied mask if any. Your kernel and iptables must include CONNMARK support. As in 1) above, may be followed by :P or :F SAME Some websites run applications that require multiple connections from a client browser. Where multiple 'balanced' providers are configured, this can lead to problems when some of the connections are routed through one provider and some through another. The SAME target allows you to work around that problem. SAME may be used in the PREROUTING and OUTPUT chains. When used in PREROUTING, it causes matching connections from an individual local system to all use the same provider. For example: #ACTION SOURCE DEST PROTO DEST # PORT(S) SAME:P 192.168.1.0/24 0.0.0.0/0 tcp 80,443 If a host in 192.168.1.0/24 attempts a connection on TCP port 80 or 443 and it has sent a packet on either of those ports in the last five minutes then the new connection will use the same provider as the connection over which that last packet was sent. When used in the OUTPUT chain, it causes all matching connections to an individual remote system to all use the same provider. For example:#ACTION SOURCE DEST PROTO DEST # PORT(S) SAME $FW 0.0.0.0/0 tcp 80,443 If the firewall attempts a connection on TCP port 80 or 443 and it has sent a packet on either of those ports in the last five minutes to the same remote system then the new connection will use the same provider as the connection over which that last packet was sent. SAVE[/mask] -- save the packet's mark to the connection's mark using the supplied mask if any. Your kernel and iptables must include CONNMARK support. As in 1) above, may be followed by :P or :F STATE {NEW|RELATED|ESTABLISHED|INVALID} [,...] Added in Shorewall 4.5.9. The rule will only match if the packet's connection is in one of the listed states. TOS(tos[/mask]) Added in Shorewall 4.5.1. Sets the Type of Service field in the IP header. The tos value may be given as an number (hex or decimal) or as the name of a TOS type. Valid type names and their associated hex numeric values are: Minimize-Delay => 0x10, Maximize-Throughput => 0x08, Maximize-Reliability => 0x04, Minimize-Cost => 0x02, Normal-Service => 0x00 To indicate more than one class, add their hex values together and specify the result. When tos is given as a number, it may be optionally followed by '/' and a mask. When no mask is given, the value 0xff is assumed. When tos is given as a type name, the mask 0x3f is assumed. The action performed is to zero out the bits specified by the mask, then set the bits specified by tos. May be optionally followed by ':' and a capital letter designating the chain where classification is to occur. F FORWARD chain. T POSTROUTING chain. TPROXY(mark[,[port][,[address]]]) -- FORMAT 1 Transparently redirects a packet without altering the IP header. Requires a local provider to be defined in shorewall-providers(5). There are three parameters to TPROXY - only the first (mark) is required: mark - the MARK value corresponding to the local provider in shorewall-providers(5). port - the port on which the proxy server is listening. If omitted, the original destination port. address - a local (to the firewall) IP address on which the proxy server is listening. If omitted, the IP address of the interface on which the request arrives. TPROXY([port][,address]) -- FORMAT 2 Transparently redirects a packet without altering the IP header. Requires a tproxy provider to be defined in shorewall-providers(5). There are three parameters to TPROXY - neither is required: port - the port on which the proxy server is listening. If omitted, the original destination port. address - a local (to the firewall) IP address on which the proxy server is listening. If omitted, the IP address of the interface on which the request arrives. TTL([-|+]number) Added in Shorewall 4.4.24. Prior to Shorewall 4.5.7.2, may be optionally followed by :F but the resulting rule is always added to the FORWARD chain. Beginning with Shorewall 4.5.7.s, it may be optionally followed by :P, in which case the rule is added to the PREROUTING chain. If + is included, packets matching the rule will have their TTL incremented by number. Similarly, if - is included, matching packets have their TTL decremented by number. If neither + nor - is given, the TTL of matching packets is set to number. The valid range of values for number is 1-255.
SOURCE - {-|{interface|$FW}|[{interface|$FW}:]address-or-range[,address-or-range]...}[exclusion] May be: An interface name - matches traffic entering the firewall on the specified interface. May not be used in classify rules or in rules using the :T chain qualifier. A comma-separated list of host or network IP addresses or MAC addresses. This form will not match traffic that originates on the firewall itself unless either <major><minor> or the :T chain qualifier is used in the ACTION column. Examples: 0.0.0.0/0 192.168.1.0/24, 172.20.4.0/24 An interface name followed by a colon (":") followed by a comma-separated list of host or network IP addresses or MAC addresses. May not be used in classify rules or in rules using the :T chain qualifier. $FW optionally followed by a colon (":") and a comma-separated list of host or network IP addresses. Matches packets originating on the firewall. May not be used with a chain qualifier (:P, :F, etc.) in the ACTION column. MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion(5)). DEST - {-|{interface|$FW}|[{interface|$FW}:]address-or-range[,address-or-range]...}[exclusion] May be: An interface name. May not be used in the PREROUTING chain (:P in the mark column or no chain qualifier and MARK_IN_FORWARD_CHAIN=No in shorewall.conf (5)). The interface name may be optionally followed by a colon (":") and an IP address list. A comma-separated list of host or network IP addresses. The list may include ip address ranges if your kernel and iptables include iprange support. Beginning with Shorewall 4.4.13, $FW may be specified by itself or qualified by an address list. This causes marking to occur in the INPUT chain. You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall-exclusion(5)). PROTO - {-|{tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}[,...]} Protocol - ipp2p requires ipp2p match support in your kernel and iptables. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. PORT(S) (dport) - [-|port-name-number-or-range[,port-name-number-or-range]...] Optional destination Ports. A comma-separated list of Port names (from services(5)), port numbers or port ranges; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). ICMP types may be specified as a numeric type, a numeric type and code separated by a slash (e.g., 3/4), or a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP. If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example bit for bit-torrent). If no PORT is given, ipp2p is assumed. An entry in this field requires that the PROTO column specify icmp (1), tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following field is supplied. SOURCE PORT(S) (sport) - [-|port-name-number-or-range[,port-name-number-or-range]...] Optional source port(s). If omitted, any source port is acceptable. Specified as a comma-separated list of port names, port numbers or port ranges. An entry in this field requires that the PROTO column specify tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following fields is supplied. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel. USER - [!][user-name-or-number][:group-name-or-number][+program-name] This optional column may only be non-empty if the SOURCE is the firewall itself. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given). Examples: joe program must be run by joe :kids program must be run by a member of the 'kids' group !:kids program must not be run by a member of the 'kids' group +upnpd #program named upnpd The ability to specify a program name was removed from Netfilter in kernel version 2.6.14. TEST - [!]value[/mask][:C] Optional - Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. LENGTH - [length|[min]:[max]] Optional - packet payload length. This field, if present allow you to match the length of a packet payload (Layer 4 data ) against a specific value or range of values. You must have iptables length support for this to work. A range is specified in the form min:max where either min or max (but not both) may be omitted. If min is omitted, then 0 is assumed; if max is omitted, than any packet that is min or longer will match. TOS - tos Type of service. Either a standard name, or a numeric value to match. Minimize-Delay (16) Maximize-Throughput (8) Maximize-Reliability (4) Minimize-Cost (2) Normal-Service (0) CONNBYTES - [!]min:[max[:{O|R|B}[:{B|P|A}]]] Optional connection Bytes; defines a byte or packet range that the connection must fall within in order for the rule to match. A packet matches if the the packet/byte count is within the range defined by min and max (unless ! is given in which case, a packet matches if the packet/byte count is not within the range). min is an integer which defines the beginning of the byte/packet range. max is an integer which defines the end of the byte/packet range; if omitted, only the beginning of the range is checked. The first letter gives the direction which the range refers to:
O - The original direction of the connection. - The opposite direction from the original connection. B - The total of both directions.
If omitted, B is assumed. The second letter determines what the range refers to.
B - Bytes P - Packets A - Average packet size.
If omitted, B is assumed.
HELPER - helper Names a Netfilter protocol helper module such as , , , etc. A packet will match if it was accepted by the named helper module. Example: Mark all FTP data connections with mark 4:#ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST LENGTH TOS CONNBYTES HELPER # PORT(S) 4:T 0.0.0.0/0 0.0.0.0/0 TCP - - - - - - - ftp PROBABILITY - [probability] Added in Shorewall 4.5.0. When non-empty, requires the Statistics Match capability in your kernel and ip6tables and causes the rule to match randomly but with the given probability. The probability is a number 0 < probability <= 1 and may be expressed at up to 8 decimal points of precision. DSCP - [[!]dscp] Added in Shorewall 4.5.1. When non-empty, match packets whose Differentiated Service Code Point field matches the supplied value (when '!' is given, the rule matches packets whose DSCP field does not match the supplied value). The dscp value may be given as an even number (hex or decimal) or as the name of a DSCP class. Valid class names and their associated hex numeric values are: CS0 => 0x00 CS1 => 0x08 CS2 => 0x10 CS3 => 0x18 CS4 => 0x20 CS5 => 0x28 CS6 => 0x30 CS7 => 0x38 BE => 0x00 AF11 => 0x0a AF12 => 0x0c AF13 => 0x0e AF21 => 0x12 AF22 => 0x14 AF23 => 0x16 AF31 => 0x1a AF32 => 0x1c AF33 => 0x1e AF41 => 0x22 AF42 => 0x24 AF43 => 0x26 EF => 0x2e
Example Example 1: Mark all ICMP echo traffic with packet mark 1. Mark all peer to peer traffic with packet mark 4. 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 means unclassified. #ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST # PORT(S) 1:T 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1:T 0.0.0.0/0 0.0.0.0/0 icmp echo-reply RESTORE:T 0.0.0.0/0 0.0.0.0/0 all - - - 0 CONTINUE:T 0.0.0.0/0 0.0.0.0/0 all - - - !0 4:T 0.0.0.0/0 0.0.0.0/0 ipp2p:all SAVE:T 0.0.0.0/0 0.0.0.0/0 all - - - !0 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. Example 2: SNAT outgoing connections on eth0 from 192.168.1.0/24 in round-robin fashion between addresses 1.1.1.1, 1.1.1.3, and 1.1.1.9 (Shorewall 4.5.9 and later). /etc/shorewall/tcrules: #ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST # PORT(S) 1-3:CF 192.168.1.0/24 eth0 ; state=NEW /etc/shorewall/masq: #INTERFACE SOURCE ADDRESS ... eth0 192.168.1.0/24 1.1.1.1 ; mark=1:C eth0 192.168.1.0/24 1.1.1.3 ; mark=2:C eth0 192.168.1.0/24 1.1.1.4 ; mark=3:C FILES /etc/shorewall/tcrules See ALSO http://shorewall.net/traffic_shaping.htm http://shorewall.net/MultiISP.html http://shorewall.net/PacketMarking.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-ecn(5), shorewall-exclusion(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-blrules.xml0000644000175000017500000003043412222401136023203 0ustar teastepteastep shorewall-blrules 5 blrules shorewall Blacklist file /etc/shorewall/blrules Description This file is used to perform blacklisting and whitelisting. Rules in this file are applied depending on the setting of BLACKLISTNEWONLY in shorewall.conf(5). If BLACKLISTNEWONLY=No, then they are applied regardless of the connection tracking state of the packet. If BLACKLISTNEWONLY=Yes, they are applied to connections in the NEW and INVALID states. The format of rules in this file is the same as the format of rules in shorewall-rules (5). The difference in the two files lies in the ACTION (first) column. ACTION- {ACCEPT|BLACKLIST|blacklog|CONTINUE|DROP|A_DROP|REJECT|A_REJECT|WHITELIST|LOG|QUEUE|NFQUEUE[(queuenumber)]|[?]COMMENT|action|macro[(target)]}[:{log-level|none}[!][:tag]] Specifies the action to be taken if the packet matches the rule. Must be one of the following. BLACKLIST Added in Shorewall 4.5.3. This is actually a macro that expands as follows: If BLACKLIST_LOGLEVEL is specified in shorewall.conf(5), then the macro expands to blacklog. Otherwise it expands to the action specified for BLACKLIST_DISPOSITION in shorewall.conf(5). blacklog May only be used if BLACKLIST_LOGLEVEL is specified in shorewall.conf (5). Logs, audits (if specified) and applies the BLACKLIST_DISPOSITION specified in shorewall.conf (5). ACCEPT|CONTINUE|WHITELIST Exempt the packet from the remaining rules in this file. DROP Ignore the packet. A_DROP and A_DROP! Audited versions of DROP. Requires AUDIT_TARGET support in the kernel and ip6tables. REJECT disallow the packet and return an icmp-unreachable or an RST packet. A_REJECT Audited versions of REJECT. Require AUDIT_TARGET support in the kernel and ip6tables. LOG Simply log the packet and continue with the next rule. QUEUE Queue the packet to a user-space application such as ftwall (http://p2pwall.sf.net). The application may reinsert the packet for further processing. NFLOG[(nflog-parameters)] queues matching packets to a back end logging daemon via a netlink socket then continues to the next rule. See http://www.shorewall.net/shorewall_logging.html. NFQUEUE Queues the packet to a user-space application using the nfnetlink_queue mechanism. If a queuenumber is not specified, queue zero (0) is assumed. [?]COMMENT The rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries. The comment will appear delimited by "/* ... */" in the output of "shorewall show <chain>". To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. action The name of an action declared in shorewall-actions(5) or in /usr/share/shorewall/actions.std. macro The name of a macro defined in a file named macro.macro. If the macro accepts an action parameter (Look at the macro source to see if it has PARAM in the TARGET column) then the macro name is followed by the parenthesized target (ACCEPT, DROP, REJECT, ...) to be substituted for the parameter. Example: FTP(ACCEPT). The ACTION may optionally be followed by ":" and a syslog log level (e.g, REJECT:info or Web(ACCEPT):debug). This causes the packet to be logged at the specified level. If the ACTION names an action declared in shorewall-actions(5) or in /usr/share/shorewall/actions.std then: If the log level is followed by "!' then all rules in the action are logged at the log level. If the log level is not followed by "!" then only those rules in the action that do not specify logging are logged at the specified level. The special log level none! suppresses logging by the action. You may also specify NFLOG (must be in upper case) as a log level.This will log to the NFLOG target for routing to a separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html). Actions specifying logging may be followed by a log tag (a string of alphanumeric characters) which is appended to the string generated by the LOGPREFIX (in shorewall.conf(5)). For the remaining columns, see shorewall-rules (5). Example Example 1: Drop Teredo packets from the net. DROP net:[2001::/32] all Example 2: Don't subject packets from 2001:DB8::/64 to the remaining rules in the file. WHITELIST net:[2001:DB8::/64] all FILES /etc/shorewall/blrules See ALSO http://shorewall.net/blacklisting_support.htm http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-hosts(5), shorewall-interfaces(5), shorewall-maclist(5), shorewall6-netmap(5),shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-ecn.xml0000644000175000017500000000461612222401136022303 0ustar teastepteastep shorewall-ecn 5 ecn Shorewall ECN file /etc/shorewall/ecn Description Use this file to list the destinations for which you want to disable ECN (Explicit Congestion Notification). The columns in the file are as follows. INTERFACE - interface Interface through which host(s) communicate with the firewall HOST(S) (Optional) - [-|address-or-address-range[,address-or-address-range]...] Comma-separated list of host and/or network addresses. If left empty or supplied as "-", 0.0.0.0/0 is assumed. If your kernel and iptables include iprange match support then IP address ranges are also permitted. FILES /etc/shorewall/ecn See ALSO shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-proxyarp.xml0000644000175000017500000001247512222401136023424 0ustar teastepteastep shorewall-proxyarp 5 proxyarp Shorewall Proxy ARP file /etc/shorewall/proxyarp Description This file is used to define Proxy ARP. There is one entry in this file for each IP address to be proxied. The columns in the file are as follows. ADDRESS - address IP Address. INTERFACE - interface (Optional as of Shorewall 4.4.16) Local interface where system with the ip address in ADDRESS is connected. This column is only required when HAVEROUTE is set to No (no) or is left empty. EXTERNAL - interface External Interface to be used to access this system from the Internet. HAVEROUTE - [-|Yes|No] If there is already a route from the firewall to the host whose address is given, enter Yes or yes in this column. Otherwise, enter no or No or leave the column empty and Shorewall will add the route for you. If Shorewall adds the route, its persistence depends on the value of thePERSISTENT column contains Yes; otherwise, shorewall stop or shorewall clear will delete the route. PERSISTENT - [-|Yes|No] If HAVEROUTE is No or no, then the value of this column determines if the route added by Shorewall persists after a shorewall stop or a shorewall clear. If this column contains Yes or yes then the route persists; If the column is empty or contains No or no then the route is deleted by shorewall stop or shorewall clear. Example Example 1: Host with IP 155.186.235.6 is connected to interface eth1 and we want hosts attached via eth0 to be able to access it using that address. #ADDRESS INTERFACE EXTERNAL 155.186.235.6 eth1 eth0 FILES /etc/shorewall/proxyarp See ALSO http://shorewall.net/ProxyARP.htm http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-tcclasses.xml0000644000175000017500000010071212222401136023514 0ustar teastepteastep shorewall-tcclasses 5 tcclasses Shorewall file to define HTB and HFSC classes /etc/shorewall/tcclasses Description A note on the rate/bandwidth definitions used in this file: don't use a space between the integer value and the unit: 30kbit is valid while 30 kbit is NOT. you can use one of the following units: kpbs Kilobytes per second. mbps Megabytes per second. kbit Kilobits per second. mbit Megabits per second. bps or number Bytes per second. if you want the values to be calculated for you depending on the output bandwidth setting defined for an interface in tcdevices, you can use expressions like the following: full/3 causes the bandwidth to be calculated as 1/3 of the full outgoing speed that is defined. full*9/10 will set this bandwidth to 9/10 of the full bandwidth Note that in a sub-class (a class that has a specified parent class), full refers to the RATE or CEIL of the parent class rather than to the OUT-BANDWIDTH of the device. DO NOT add a unit to the rate if it is calculated ! The columns in the file are as follows. INTERFACE - interface[[:parent]:class] Name of interface. You may specify the interface number rather than the interface name. If the classify option is given for the interface in shorewall-tcdevices(5), then you must also specify an interface class (an integer that must be unique within classes associated with this interface). If the classify option is not given, you may still specify a class or you may have Shorewall generate a class number from the MARK value. Interface numbers and class numbers are always assumed to be specified in hex and class number 1 is reserved as the root class of the queuing discipline. You may NOT specify wildcards here, e.g. if you have multiple ppp interfaces, you need to put them all in here! Please note that you can only use interface names in here that have a bandwidth defined in the shorewall-tcdevices(5) file. 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 -- the number of a class that you have previously defined. The sub-class may borrow unused bandwidth from its parent. MARK - {-|value} The mark value which is an integer in the range 1-255. You set mark values in the shorewall-tcrules(5) file, marking the traffic you want to fit in the classes defined in here. Must be specified as '-' if the classify option is given for the interface in shorewall-tcdevices(5) and you are running Shorewall 4.5.5 or earlier. You can use the same marks for different interfaces. RATE - {-|rate[:dmax[:umax]]} The minimum bandwidth this class should get, when the traffic load rises. If the sum of the rates in this column exceeds the INTERFACE's OUT-BANDWIDTH, then the OUT-BANDWIDTH limit may not be honored. Similarly, if the sum of the rates of sub-classes of a class exceed the CEIL of the parent class, things don't work well. When using the HFSC queuing discipline, this column specify the real-time (RT) service curve. leaf classes may specify dmax, the maximum delay in milliseconds that the first queued packet for this class should experience. May be expressed as an integer, optionally followed by 'ms' with no intervening white-space (e.g., 10ms). HFSC leaf classes may also specify umax, the largest packet expected in this class. May be expressed as an integer. The unit of measure is bytes and the integer may be optionally followed by 'b' with no intervening white-space (e.g., 800b). umax may only be given if dmax is also given. Beginning with Shorewall 4.5.6, HFSC classes may omit this column (e.g, '-' in the column), provided that an lsrate is specified (see CEIL below). These rates are used to arbitrate between classes of the same priority. CEIL - [lsrate:]rate 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 needed services (e.g. ssh) are not used. You can use the value full in here for setting the maximum bandwidth to the RATE of the parent class, or the OUT-BANDWIDTH of the device if there is no parent class. Beginning with Shorewall 4.5.6, you can also specify an lsrate (link sharing rate). PRIORITY - priority For HTB:
The priority in which classes will be serviced by the packet shaping scheduler and also the priority in which bandwidth in excess of the rate will be given to each class. Higher priority classes will experience less delay since they are serviced first. Priority values are serviced in ascending order (e.g. 0 is higher priority than 1). Classes may be set to the same priority, in which case they will be serviced as equals.
For both HTB and HFSC, the priority is used to calculate the priority of following Shorewall-generated classification filters that refer to the class: Packet MARK tcp-ack and the tos options (see below) The rules for classes with lower numeric priorities will appear before those with higher numeric priorities. Beginning with Shorewall 4.5.8, the PRIORITY may be omitted from an HFSC class if you do not use the MARK column or the tcp-ack or tos options. If you use any of those features and omit the PRIORITY, then you must specify a priority along with the MARK or option.
OPTIONS (Optional) - [option[,option]...] 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. You must define default for exactly one class per interface. tos=0xvalue[/0xmask][:priority] (mask defaults to 0xff) This lets you define a classifier for the given value/mask combination of the IP packet's TOS/Precedence/DiffSrv octet (aka the TOS byte). Beginning with Shorewall 4.5.8, the value/mask may be followed by a colon (":") and a priority. This priority determines the order in which filter rules are processed during packet classification. If not specified, the value (class priority << 8) | 10) is used. tos-tosname[:priority] Aliases for the following TOS octet value and mask encodings. TOS encodings of the "TOS byte" have been deprecated in favor of diffserve classes, but programs like ssh, rlogin, and ftp still use them. Beginning with Shorewall 4.5.8, the tos-name may be followed by a colon (":") and a priority. This priority determines the order in which filter rules are processed during packet classification. If not specified, the value (class priority << 8) | 10) is used. tos-minimize-delay 0x10/0x10 tos-maximize-throughput 0x08/0x08 tos-maximize-reliability 0x04/0x04 tos-minimize-cost 0x02/0x02 tos-normal-service 0x00/0x1e Each of these options is only valid for ONE class per interface. tcp-ack[:priority] If defined, causes a tc filter to be created that puts all tcp ack packets on that interface that have a 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 because we want only packets WITHOUT payload to match. Beginning with Shorewall 4.5.8, the tcp-ack may be followed by a colon (":") and a priority. This priority determines the order in which filter rules are processed during packet classification. If not specified, the value (class priority << 8) | 20) is used. This option is only valid for ONE class per interface. occurs=number Typically used with an IPMARK entry in 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 tcrules (5). flow=keys Shorewall attaches an SFQ queuing discipline to each leaf HTB 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 classifier must be used carefully or it can block off all traffic on an interface! The flow option can be specified for an HTB 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 NAT as the key.
pfifo When specified for a leaf class, the pfifo queuing 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, determines the maximum number of packets that may be queued within the class. The number must be > 2 and <=128. If not specified, the value 127 is assumed. red=(redoption=value, ...) Added in Shorewall 4.5.6. When specified on a leaf class, causes the class to use the RED (Random Early Detection) queuing discipline rather than SFQ. See tc-red (8) for additional information. Allowable redoptions are: min min Average queue size at which marking becomes a possibility. max max At this average queue size, the marking probability is maximal. Must be at least twice min to prevent synchronous retransmits, higher for low min. probability probability Maximum probability for marking, specified as a floating point number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%, respectively). limit limit Hard limit on the real (not average) queue size in bytes. Further packets are dropped. Should be set higher than max+burst. It is advised to set this a few times higher than max. Shorewall requires that limit be at least twice min. burst burst Used for determining how fast the average queue size is influenced by the real queue size. Larger values make the calculation more sluggish, allowing longer bursts of traffic before marking starts. Real life experiments support the following guide‐line: (min+min+max)/(3*avpkt). avpkt avpkt Optional. Specified in bytes. Used with burst to determine the time constant for average queue size calculations. 1000 is a good value and is the Shorewall default. bandwidth bandwidth Optional. This rate is used for calculating the average queue size after some idle time. Should be set to the bandwidth of your interface. Does not mean that RED will shape for you! ecn RED can either 'mark' or 'drop'. Explicit Congestion Notification allows RED to notify remote hosts that their rate exceeds the amount of bandwidth available. Non-ECN capable hosts can only be notified by dropping a packet. If this parameter is specified, packets which indicate that their hosts honor ECN will only be marked and not dropped, unless the queue size hits limit bytes. Recommended. fq_codel[=(codeloption=value, ...)] Added in Shorewall 4.5.12. When specified for 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. Allowable codeloptions are: limit hard limit on the real queue size. When this limit is reached, incoming packets are dropped. If the value is lowered, packets are dropped so that the new limit is met. Default is 1000 packets. flows is the number of flows into which the incoming packets are classified. Due to the stochastic nature of hashing, multiple flows may end up being hashed into the same slot. Newer flows have priority over older ones. This parameter can be set only at load time since memory has to be allocated for the hash table. Default value is 1024. target is the acceptable minimum standing/persistent queue delay. This minimum delay is identified by tracking the local minimum queue delay that packets experience. Default and recommended value is 5ms. interval is used to ensure that the measured minimum delay does not become too stale. The minimum delay must be experienced in the last epoch of length interval. It should be set on the order of the worst-case RTT through the bottleneck to give endpoints sufficient time to react. Default value is 100ms. quantum is the number of bytes used as 'deficit' in the fair queuing algorithm. Default is set to 1514 bytes which corresponds to the Ethernet MTU plus the hardware header length of 14 bytes. ecn | noecn can be used to mark packets instead of dropping them. If ecn has been enabled, noecn can be used to turn it off and vice-versa. By default, ecn is enabled.
Examples Example 1: Suppose you are using PPP over Ethernet (DSL) and ppp0 is the interface for this. You have 4 classes here, the first you can use for voice over IP traffic, the second interactive traffic (e.g. ssh/telnet but not scp), the third will be for all unclassified traffic, and the forth is for low priority traffic (e.g. peer-to-peer). The voice traffic in the first class will be guaranteed a minimum of 100kbps and always be serviced first (because of the low priority number, giving less delay) and will be granted excess bandwidth (up to 180kbps, the class ceiling) first, before any other traffic. A single VoIP stream, depending upon codecs, after encapsulation, can take up to 80kbps on a PPPoE/DSL link, so we pad a little bit just in case. (TOS byte values 0xb8 and 0x68 are DiffServ classes EF and AFF3-1 respectively and are often used by VOIP devices). Interactive traffic (tos-minimum-delay) and TCP acks (and ICMP echo traffic if you use the example in tcrules) and any packet with a mark of 2 will be guaranteed 1/4 of the link bandwidth, and may extend up to full speed of the link. Unclassified traffic and packets marked as 3 will be guaranteed 1/4th of the link bandwidth, and may extend to the full speed of the link. Packets marked with 4 will be treated as low priority packets. (The tcrules example marks p2p traffic as such.) If the link is congested, they're only guaranteed 1/8th of the speed, and even if the link is empty, can only expand to 80% of link bandwidth just as a precaution in case there are upstream queues we didn't account for. This is the last class to get additional bandwidth and the last to get serviced by the scheduler because of the low priority. #INTERFACE MARK RATE CEIL PRIORITY OPTIONS ppp0 1 100kbit 180kbit 1 tos=0x68/0xfc,tos=0xb8/0xfc ppp0 2 full/4 full 2 tcp-ack,tos-minimize-delay ppp0 3 full/4 full 3 default ppp0 4 full/8 full*8/10 4 FILES /etc/shorewall/tcclasses See ALSO http://shorewall.net/traffic_shaping.htm http://shorewall.net/configuration_file_basics.htm#Pairs tc-hfsc(7) tc-red(8) shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-template.xml0000644000175000017500000000313012222401136023337 0ustar teastepteastep shorewall- 5 file Shorewall file /etc/shorewall/ Description The columns in the file are as follows. COLUMN 1 Example FILES /etc/shorewall/ See ALSO shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages/shorewall-arprules.xml0000644000175000017500000002701012222401136023364 0ustar teastepteastep shorewall-arprules 5 arprules Shorewall ARP rules file /etc/shorewall/arprules Description This file was added in Shorewall 4.5.12 and is used to describe low-level rules managed by arptables (8). These rules only affect Address Resolution Protocol (ARP), Reverse Address Resolution Protocol (RARP) and Dynamic Reverse Address Resolution Protocol (DRARP) frames. The columns in the file are as shown below. MAC addresses are specified normally (6 hexadecimal numbers separated by colons). ACTION Describes the action to take when a frame matches the criteria in the other columns. Possible values are: ACCEPT This is the default action if no rules matches a frame; it lets the frame go through. DROP Causes the frame to be dropped. SNAT:ip-address Modifies the source IP address to the specified ip-address. DNAT:ip-address Modifies the destination IP address to the specified ip-address. SMAT:mac-address Modifies the source MAC address to the specified mac-address. DMAT:mac-address Modifies the destination MAC address to the specified mac-address. SNATC:ip-address Like SNAT except that the frame is then passed to the next rule. DNATC:ip-address Like DNAT except that the frame is then passed to the next rule. SMATC:mac-address Like SMAT except that the frame is then passed to the next rule. DMATC:mac-address Like DMAT except that the frame is then passed to the next rule. SOURCE - [interface[:[!]ipaddress[/ipmask][:[!]macaddress[/macmask]]]] Where interface Is an interface defined in shorewall-interfaces(5). ipaddress is an IPv4 address. DNS names are not allowed. ipmask specifies a mask to be applied to ipaddress. macaddress The source MAC address. macmask Mask for MAC address; must be specified as 6 hexadecimal numbers separated by colons. When '!' is specified, the test is inverted. If not specified, matches only frames originating on the firewall itself. Either SOURCE or DEST must be specified. DEST - [interface[:[!]ipaddress[/ipmask][:[!]macaddress[/macmask]]]] Where interface Is an interface defined in shorewall-interfaces(5). ipaddress is an IPv4 address. DNS Names are not allowed. ipmask specifies a mask to be applied to frame addresses. macaddress The destination MAC address. macmask Mask for MAC address; must be specified as 6 hexadecimal numbers separated by colons. When '!' is specified, the test is inverted and the rule matches frames which do not match the specified address/mask. If not specified, matches only frames originating on the firewall itself. If both SOURCE and DEST are specified, then both interfaces must be bridge ports on the same bridge. Either SOURCE or DEST must be specified. ARP OPCODE - [[!]opcode] Optional. Describes the type of frame. Possible opcode values are: 1 ARP Request 2 ARP Reply 3 RARP Request 4 RARP Reply 5 Dynamic RARP Request 6 Dynamic RARP Reply 7 Dynamic RARP Error 8 InARP Request 9 ARP NAK When '!' is specified, the test is inverted and the rule matches frames which do not match the specified opcode. Example The eth1 interface has both a public IP address and a private address (10.1.10.11/24). When sending ARP requests to 10.1.10.0/24, use the private address as the IP source: #ACTION SOURCE DEST ARP OPCODE SNAT:10.1.10.11 - eth1:10.1.10.0/24 1 FILES /etc/shorewall/arprules shorewall-docs-xml-4.5.21/ports.xml0000644000175000017500000005345612222401136017122 0ustar teastepteastep
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 DESTINATION 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 DESTINATION PROTO DEST PORT(S) FTP(ACCEPT) <source> <destination> You would code your rule as follows: #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) 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 DEST PORT(S) BitTorrent(ACCEPT)<source> <destination>
DNS #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) 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 DEST PORT(S) 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 DEST PORT(S) 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 DEST PORT(S) Gnutella(DNAT) net loc:192.168.1.4
ICQ/AIM #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) IMAP(ACCEPT) <source> <destination> # Unsecure IMAP IMAPS(ACCEPT) <source> <destination> # IMAP over SSL.
IPSEC #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) 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 DEST PORT(S) MySQL(ACCEPT) <source> <destination>
NFS #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) NTP(ACCEPT) <source> <destination>
<trademark>PCAnywhere</trademark> #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) POP3(ACCEPT) <source> <destination> # Secure POP3S(ACCEPT) <source> <destination> #Unsecure Pop3
PPTP #ACTION SOURCE DESTINATION PROTO DEST PORT(S) ACCEPT <source> <destination> 47 ACCEPT <source> <destination> tcp 1723 Lots more information here and here.
rdate #ACTION SOURCE DESTINATION PROTO DEST PORT(S) Rdate(ACCEPT) <source> <destination>
rsync #ACTION SOURCE DESTINATION PROTO DEST PORT(S) Rsync(ACCEPT) <source> <destination>
Siproxd This assumes siproxd is running on the firewall and is using the default ports. #ACTION SOURCE DESTINATION PROTO DEST PORT(S) REDIRECT loc 5060 udp 5060 ACCEPT net fw udp 5060 ACCEPT net fw udp 7070:7089
SSH/SFTP #ACTION SOURCE DESTINATION PROTO DEST PORT(S) SSH(ACCEPT)<source> <destination>
SMB/NMB (Samba/<trademark>Windows</trademark> Browsing/File Sharing) #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) SMTP(ACCEPT) <source> <destination> #Insecure SMTP SMTPS(ACCEPT) <source> <destination> #SMTP over SSL (TLS)
SNMP #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) SVN(ACCEPT) <source> <destination>
Telnet The telnet protocol is very insecure, don't use it. #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) ACCEPT <source> <destination> udp 69
Traceroute #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) ACCEPT fw net icmp ACCEPT fw loc icmp ACCEPT fw ...
Usenet (NNTP) #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) VNC(ACCEPT) <source> <destination> Vncserver to Vncviewer in listen mode -- TCP port 5500. #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) HTTP(ACCEPT) <source> <destination> #Insecure HTTP HTTPS(ACCEPT) <source> <destination> #Secure HTTP
Webmin #ACTION SOURCE DESTINATION PROTO DEST PORT(S) Webmin(ACCEPT) <source> <destination> Webmin use TCP port 10000.
Whois #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) 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-4.5.21/shorewall_quickstart_guide.xml0000644000175000017500000001042312222401136023365 0ustar teastepteastep
Shorewall QuickStart Guides (HOWTOs) 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. Do not attempt to install Shorewall on a remote system. You are virtually assured to lock yourself out of that system. With thanks to Richard who reminded me once again that we must all first walk before we can run. The French Translations of the single-IP guides are courtesy of Patrice Vetsel. Updated for Shorewall 2.0 by Fabien Demassieux and for 3.0 by Guy Marcenac. The Russian Translations are courtesy of Alex at tut.by.
Before You Start Please read the short article Introduction to Shorewall to familiarize yourself with basic Shorewall concepts.
The Guides These guides provide step-by-step instructions for configuring Shorewall in common firewall setups.
If you want the firewall system to handle a <emphasis role="bold">single public IP address</emphasis> These guides are designed to get your first firewall up and running quickly in the three most common Shorewall configurations. If you want to learn more about Shorewall than is explained in these simple guides then the Shorewall Setup Guide (Version Française) is for you. Standalone Linux System (Version Française) (Russian Version) Version en Español Two-interface Linux System acting as a firewall/router for a small local network (Version Française) (Russian Version) Three-interface Linux System acting as a firewall/router for a small local network and a DMZ.. (Version Française) (Russian Version)
If you want the firewall system to handle more than one public IP address The Shorewall Setup Guide (Version Française) outlines the steps necessary to set up a firewall where there are multiple public IP addresses involved or if you want to learn more about Shorewall than is explained in the single-address guides above.
shorewall-docs-xml-4.5.21/standalone_fr.xml0000644000175000017500000007756212222401136020576 0ustar teastepteastep
Firewall Monoposte (une interface) Version Française de Standalone 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 révision 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, puis 4 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 Configurer Shorewall sur un système isolé Linux est très simple si vous comprenez les bases et 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 Une seule adresse IP externe Une connexion passant par un modem câble, ADSL, ISDN-RNIS, Frame Relay, RTC... ou bien une connexion à un réseau local (LAN) et vous souhaitez simplement protéger votre système Linux des autres systèmes sur ce réseau local.
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]#
Avant de commencer 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. 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. Version Windows de dos2unix Version Linux de dos2unix
Conventions Les points ou les modifications qui s'imposent sont indiqués par .
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. Après avoir installé Shorewall,vous pourrez trouver les exemples de la manière suivante: Si vous avez installé shorewall en utilisant un RPM, les exemples seront dans le sous-répertoire Samples/one-interface/ 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 | 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 ~# Si vous avez installé depuis le tarball, les exemples sont dans le répertoire Samples/one-interface du tarball. Si vous avez installé en utilisant un .deb de Shorewall 3.x, les exemples sont dans /usr/share/doc/shorewall/examples/one-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/examples/one-interface. Vous n'avez pas besoin d'installer le paquetage shorewall-doc pour pouvoir accéder aux exemples. 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. 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 les fichiers de configuration fournis dans l'archive d'exemples pour une seule interface, deux zones seulement sont définies : #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 Les zones de Shorewall sont définies dans /etc/shorewall/zones. Remarquez que Shorewall reconnaît le système de firewall comme étant sa propre zone. Le nom de la zone firewall (fw dans l'exemple plus haut) 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 concernant le trafic à autoriser ou à interdire sont exprimées en utilisant les termes 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 (one-interface) contient les politiques suivantes: #SOURCE ZONE DESTINATION ZONE POLICY LOG LEVEL LIMIT:BURST $FW net ACCEPT net all DROP info all all REJECT info Ces politiques vont : Autoriser (ACCEPT) toute demande de connexion depuis le firewall vers internet Ignorer (DROP) toutes les demandes de connexion depuis internet vers votre firewall Rejeter (REJECT) toutes les autres requêtes de connexion. Shorewall à toujours besoin de cette dernière politique. A ce point, éditez votre /etc/shorewall/policy et faites y les changements que vous désirez.
Interface Externe Le firewall possède une seule interface 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 par PPPoE (Point-to-Point Protocol over Ethernet) ou par PPTP (Point-to-Point Tunneling Protocol), l'interface externe sera une interface ppp (par exemple ppp0). Si vous vous connectez par 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.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:~# Dans cette exemple, l'interface externe est eth0. Les fichiers de configuration d'exemple pour le firewall monoposte (one-interface) supposent que votre interface externe est eth0. 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 de 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. La RFC 1918 réserve des plages d'adresses IP pour 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 Ces adresses sont parfois nommées non-routables car les routeurs centraux d'internet ne transfèrent pas un paquet dont la destination est une adresse réservée par la RFC 1918. Dans certain cas cependant, les FAI (fournisseurs d'accès Internet) peuvent vous affecter une de ces adresses et utiliser la Traduction d'Adresses Réseau (NAT Network Address Translation) pour réécrire les en-têtes des paquets transmis en provenance ou à destination d'internet. Avant de lancer Shorewall, il faut impérativement 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 .
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 connaitre 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.
Permettre d'autres connexions Shorewall inclue une collection de macros qui peuvent être utilisées pour rapidement autoriser ou refuser des services. Vous pouvez trouver une liste des macros comprises dans votre version de Shorewall en utilisant la commande ls /usr/share/shorewall/macro.* ou bien la commande shorewall show macros si vous utilisez une version 3.0.3 ou ultérieure de shorewall. Si vous souhaitez autoriser des connexions depuis internet vers votre firewall et que vous avez trouvé une macro appropriée dans /etc/shorewall/macro.*, le format général d'une règle dans /etc/shorewall/rules est le suivant: #ACTION SOURCE DESTINATION PROTO DEST PORT(S) <macro>/ACCEPT net $FW Assurez-vous d'ajouter vos règles après la ligne contenant SECTION NEW. Un serveur Web et un serveur IMAP sur votre firewall, accessibles depuis l'extérieur: #ACTION SOURCE DESTINATION PROTO DEST PORT(S) Web/ACCEPT net $FW IMAP/ACCEPT net $FW Vous pouvez aussi choisir de coder vos règles directement, sans utiliser de macro pré-définie. Ceci sera nécessaire quand aucune macro pré-définie ne répond à vos besoins. Dans ce cas, le format général d'une règle dans /etc/shorewall/rules est: #ACTION SOURCE DESTINATION PROTO DEST PORT(S) ACCEPT net $FW <protocol> <port> Un serveur Web et un serveur IMAP sur votre firewall, accessibles depuis l'extérieur: #ACTION SOURCE DESTINATION PROTO DEST PORT(S) ACCEPT net $FW tcp 80 ACCEPT net $FW tcp 143 Si vous ne savez pas quel port ou protocole utilise une application donnée, allez voir ici. Je ne recommande pas d'activer telnet depuis/vers internet car il utilise du texte en clair (y compris pour le login !). Si vous voulez un accès shell à votre firewall, utilisez SSH: #ACTION SOURCE DESTINATION PROTO DEST PORT(S) SSH/ACCEPT net $FW Maintenant, éditez votre fichier de configuration /etc/shorewall/rules pour ajouter, modifier ou supprimer d'autres connexions suivant vos besoins.
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 paquets .deb doivent éditer /etc/default/shorewall et mettre startup=1. Vous devez activer le lancement de Shorewall en éditant /etc/shorewall/shorewall.conf et en y mettant STARTUP_ENABLED=Yes. 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 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.
shorewall-docs-xml-4.5.21/two-interface.xml0000644000175000017500000016744212222401136020523 0ustar teastepteastep
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/routestopped /usr/share/doc/packages/shorewall/Samples/two-interfaces/rules /usr/share/doc/packages/shorewall/Samples/two-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-common/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 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 OUT # OPTIONS 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 LOG LEVEL LIMIT:BURST 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 LOG LEVEL LIMIT:BURST $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 LOG LEVEL LIMIT:BURST 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. 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 and change the first column to the name of your external interface. If your external IP is static, you can enter it 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. 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 DEST PORT(S) 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 DEST PORT(S) 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 DEST PORT(S) 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: 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 DEST PORT(S) 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 DEST PORT(S) DNS(ACCEPT)loc $FW
Other Connections The two-interface sample includes the following rules: #ACTION SOURCE DEST PROTO DEST PORT(S) 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 (see /usr/share/shorewall/macro.*) 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 DEST PORT(S) 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 DEST PORT(S) 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 DEST PORT(S) <macro>(ACCEPT) $FW <destination zone>The general format when not using defined macros is:#ACTION SOURCE DEST PROTO DEST PORT(S) 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 DEST PORT(S) 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 DEST PORT(S) 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 DEST PORT(S) 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. A running firewall may be restarted using the shorewall restart 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 added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. Also, I don't recommend using shorewall restart; 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 BROADCAST OPTIONS loc wlan0 detect 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 PORT(S) IPSEC MARK eth0 10.0.0.0/8,\ 169.254.0.0/16,\ 172.16.0.0/12,\ 192.168.0.0/16 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-4.5.21/ipsets.xml0000644000175000017500000001567312222401136017261 0ustar teastepteastep
Shorewall and Ipsets Tom Eastep 2005 2008 2010 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 appropriate for your version.
What are Ipsets? Ipsets are an extension to Netfilter/iptables that are available in xtables-addons if they are not available in your current distribution. Instructions for installing xtables-addons may be found in the Dynamic Zones article. Ipset allows you to create one or more named sets of addresses then use those sets to define Netfilter/iptables rules. Possible uses of ipsets include: Blacklists. Ipsets provide an efficient way to represent large sets of addresses and you can maintain the lists without the need to restart or even refresh your Shorewall configuration. Zone definition. Using the /etc/shorewall/hosts file, you can define a zone based on the (dynamic) contents of an ipset. Again, you can then add or delete addresses to the ipset without restarting Shorewall. See the ipsets site (URL above) for additional information about ipsets.
Shorewall Support for Ipsets Support for ipsets was introduced in Shorewall version 2.3.0. In most places where a host or network address may be used, you may also use the name of an ipset prefaced by "+". Example: "+Mirrors" When using Shorewall, the names of ipsets are restricted as follows: They must begin with a letter (after the '+'). They must be composed of letters, digits, dashes ("-") or underscores ("_"). To generate a negative match, prefix the "+" with "!" as in "!+Mirrors". Example 1: Blacklist all hosts in an ipset named "blacklist" /etc/shorewall/blacklist#ADDRESS/SUBNET PROTOCOL PORT +blacklist Example 2: Allow SSH from all hosts in an ipset named "sshok: /etc/shorewall/rules#ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT net:+sshok $FW tcp 22 The name of the ipset can be optionally followed by a comma-separated list of flags enclosed in square brackets ([...]). Each flag is either src or dst and specifies whether it is the SOURCE address or port number or the DESTINATION address or port number that should be matched. The number of flags must be appropriate for the type of ipset. If no flags are given, Shorewall assumes that the set takes a single flag and will select the flag based on the context. For example, in the blacklist file and when the ipset appears in the SOURCE column of the rules file, src is assumed. If the ipset appears in the DEST column of the rules file, dst is assumed. Note that by using [dst] in the blacklist file, you can coerce the rule into matching the destination IP address rather than the source. Beginning with Shorewall 4.4.14, multiple source or destination matches may be specified by placing multiple set names in '+[...]' (e.g., +[myset,myotherset]). When so inclosed, the set names need not be prefixed with a plus sign. Shorewall can save/restore your ipset contents with certain restrictions: You must set SAVE_IPSETS=Yes in shorewall.conf (5). You cannot use an ipset in shorewall-routestopped (5). The restore command cannot restore ipset contents saved by the save command unless the firewall is first stopped.
Shorewall6 and Shorewall-init Support for Ipsets Ipset support in Shorewall6 was added in Shorewall 4.4.21. Unlike iptables, which has separate configurations for IPv4 and IPv6, ipset has a single configuration that handles both. This means the SAVE_IPSETS=Yes in shorewall.conf or shorewall6.conf won't work correctly because . To work around this issue, Shorewall-init is now capable restoring ipset contents during 'start' and saving them during 'stop'. To direct Shorewall-init to save/restore ipset contents, set the SAVE_IPSETS option in /etc/sysconfig/shorewall-init (/etc/default/shorewall-init on Debian and derivatives). The value of the option is a file name where the contents of the ipsets will be save to and restored from. Shorewall-init will create any necessary directories during the first 'save' operation. If you configure Shorewall-init to save/restore ipsets, be sure to set SAVE_IPSETS=No in shorewall.conf and shorewall6.conf.
shorewall-docs-xml-4.5.21/manpages6/0000755000175000017500000000000012223303501017073 5ustar teastepteastepshorewall-docs-xml-4.5.21/manpages6/shorewall6-netmap.xml0000644000175000017500000001642412222401136023176 0ustar teastepteastep shorewall6-netmap 5 netmap Shorewall6 NETMAP definition file /etc/shorewall/netmap Description This file is used to map addresses in one network to corresponding addresses in a second network. It was added in Shorewall6 4.4.23.3. To use this file, your kernel and ip6tables must have RAWPOST table support included. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). TYPE - {DNAT|SNAT}:{P|O|T} Must be DNAT or SNAT followed by :P, :O or :T to perform stateless NAT. Stateless NAT requires Rawpost Table support in your kernel and iptables (see the output of shorewall6 show capabilities). If DNAT:P, traffic entering INTERFACE and addressed to NET1 has its destination address rewritten to the corresponding address in NET2. If SNAT:T, traffic leaving INTERFACE with a source address in NET1 has it's source address rewritten to the corresponding address in NET2. If DNAT:O, traffic originating on the firewall and leaving via INTERFACE and addressed to NET1 has its destination address rewritten to the corresponding address in NET2. If DNAT:P, traffic entering via INTERFACE and addressed to NET1 has its destination address rewritten to the corresponding address in NET2. If SNAT:P, traffic entering via INTERFACE with a destination address in NET1 has it's source address rewritten to the corresponding address in NET2. If SNAT:O, traffic originating on the firewall and leaving via INTERFACE with a source address in NET1 has it's source address rewritten to the corresponding address in NET2. NET1 - network-address Network in CIDR format (e.g., 2001:470:b:227/64). Beginning in Shorewall6 4.4.24, exclusion is supported. INTERFACE - interface The name of a network interface. The interface must be defined in shorewall6-interfaces(5). Shorewall allows loose matches to wildcard entries in shorewall6-interfaces(5). For example, ppp0 in this file will match a shorewall6-interfaces(8) entry that defines ppp+. NET2 - network-address Network in CIDR format NET3 - network-address Optional - added in Shorewall 4.4.11. If specified, qualifies INTERFACE. It specifies a SOURCE network for DNAT rules and a DESTINATION network for SNAT rules. PROTO (Optional - protocol-number-or-name Only packets specifying this protocol will have their IP header modified. DEST PORT(S) (dport) - port-number-or-name-list Destination Ports. An optional comma-separated list of Port names (from services(5)), port numbers or port ranges; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). ICMP types may be specified as a numeric type, a numeric type and code separated by a slash (e.g., 3/4), or a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP. If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example bit for bit-torrent). If no PORT is given, ipp2p is assumed. An entry in this field requires that the PROTO column specify icmp (1), tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following field is supplied. SOURCE PORT(S) (sport) - port-number-or-name-list Optional source port(s). If omitted, any source port is acceptable. Specified as a comma-separated list of port names, port numbers or port ranges. An entry in this field requires that the PROTO column specify tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following fields is supplied. FILES /etc/shorewall/netmap See ALSO http://shorewall.net/netmap.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall-docs-xml-4.5.21/manpages6/shorewall6-proxyndp.xml0000644000175000017500000001240712222401136023572 0ustar teastepteastep shorewall6-proxyndp 5 proxyndp Shorewall6 Proxy NDP file /etc/shorewall6/proxyndp Description This file was added in Shorewall 4.4.16 and is used to define Proxy NDP. There is one entry in this file for each IPv6 address to be proxied. The columns in the file are as follows. ADDRESS - address IPv6 Address. INTERFACE - interface (Optional) Local interface where system with the ip address in ADDRESS is connected. Only required when the HAVEROUTE column is left empty or is set to no or No. EXTERNAL - interface External Interface to be used to access this system from the Internet. HAVEROUTE - [-|Yes|No] If there is already a route from the firewall to the host whose address is given, enter Yes or yes in this column. Otherwise, enter no or No or leave the column empty and Shorewall will add the route for you. If Shorewall6 adds the route, its persistence depends on the value of thePERSISTENT column contains Yes; otherwise, shorewall6 stop or shorewall clear6 will delete the route. PERSISTENT - [-|Yes|No] If HAVEROUTE is No or no, then the value of this column determines if the route added by Shorewall persists after a shorewall6 stop or a shorewall6 clear. If this column contains Yes or yes then the route persists; If the column is empty or contains No or no then the route is deleted by shorewall6 stop or shorewall6 clear. Example Example 1: Host with IPv6 2001:470:b:227::44 is connected to interface eth1 and we want hosts attached via eth0 to be able to access it using that address. #ADDRESS INTERFACE EXTERNAL 2001:470:b:227::44 eth1 eth0 FILES /etc/shorewall6/proxyndp See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-exclusion(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-nesting(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6.conf.xml0000644000175000017500000032004312222401136022633 0ustar teastepteastep shorewall6.conf 5 shorewall6.conf Shorewall6 global configuration file /etc/shorewall6/shorewall6.conf Description This file sets options that apply to Shorewall6 as a whole. The file consists of Shell comments (lines beginning with '#'), blank lines and assignment statements (variable=value). If the value contains shell meta characters or white-space, then it must be enclosed in quotes. Example: LOG_LEVEL="NFLOG(1,0,1)". OPTIONS Many options have as their value a log-level. Log levels are a method of describing to syslog (8) the importance of a message and a number of parameters in this file have log levels as their value. These levels are defined by syslog and are used to determine the destination of the messages through entries in /etc/syslog.conf (5). The syslog documentation refers to these as "priorities"; Netfilter calls them "levels" and Shorewall6 also uses that term. Valid levels are: 7 debug 6 info 5 notice 4 warning 3 err 2 crit 1 alert 0 emerg For most Shorewall6 logging, a level of 6 (info) is appropriate. Shorewall6 log messages are generated by NetFilter and are logged using facility 'kern' 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. If you have built your kernel with NFLOG target support, you may also specify a log level of NFLOG (must be all caps). Rather than log its messages to syslogd, Shorewall6 will direct netfilter to log the messages via the NFLOG target which will send them to a process called 'ulogd'. ulogd is available with most Linux distributions (although it probably isn't installed by default). Ulogd is also available from http://www.netfilter.org/projects/ulogd/index.html and can be configured to log all Shorewall6 message to their own log file The following options may be set in shorewall6.conf. ACCEPT_DEFAULT={action[(parameters)][:level]|none} DROP_DEFAULT={action[(parameters)][:level]|none} NFQUEUE_DEFAULT={action[(parameters)][:level]|none} QUEUE_DEFAULT={action[(parameters)][:level]|none} REJECT_DEFAULT={action[(parameters)][:level]|none} 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 three are similar for ACCEPT, QUEUE and NFQUEUE policies. The value applied to these may be: a) The name of an action. The name may optionally be followed by a comma-separated list of parameters enclosed in parentheses if the specified action accepts parameters (e.g., 'Drop(audit)'). c) None or none The default values are: DROP_DEFAULT="Drop" REJECT_DEFAULT="Reject" ACCEPT_DEFAULT="none" QUEUE_DEFAULT="none" NFQUEUE_DEFAULT="None" If you set the value of either option to "None" then no default action will be used and the default action or macro must be specified in shorewall6-policy(5). You can pass parameters to the specified action or macro (e.g., myaction(audit,DROP)). Beginning with Shorewall 4.5.10, the action name can be followed optionally by a colon and a log level. The level will be applied to each rule in the action or macro body that does not already have a log level. ACCOUNTING=[Yes|No] Added in Shorewall 4.4.7. If set to Yes, Shorewall6 accounting is enabled (see shorewall6-accounting(5)). If not specified or set to the empty value, ACCOUNTING=Yes is assumed. ACCOUNTING_TABLE=[filter|mangle] Added in Shorewall 4.4.20. This setting determines which Netfilter table the accounting rules are added in. By default, ACCOUNTING_TABLE=filter is assumed. See also shorewall-accounting(5). ADMINISABSENTMINDED=[Yes|No] The value of this variable affects Shorewall6's stopped state. When ADMINISABSENTMINDED=No, only traffic to/from those addresses listed in shorewall6-routestopped(5) is accepted when Shorewall6 is stopped. When ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in shorewall6-routestopped(5), connections that were active when Shorewall6 stopped continue to work and all new connections from the firewall system itself are allowed. If this variable is not set or is given the empty value then ADMINISABSENTMINDED=No is assumed. IGNOREUNKNOWNVARIABLES=[Yes|No] Added in Shorewall 4.5.11. Normally, if an unknown shell variable is encountered in a configuration file (except in ?IF and ?ELSIF directives), the compiler raises a fatal error. If IGNOREUNKNOWNVARIABLES is set to Yes, then such variables simply expand to an empty string. Default is No. AUTOCOMMENT=[Yes|No] Formerly named AUTO_COMMENT. If set, if there is not a current comment when a macro is invoked, the behavior is as if the first line of the macro file was "COMMENT <macro name>". The AUTO_COMMENT option has a default value of 'Yes'. AUTOHELPERS=[Yes|No] Added in Shorewall 4.5.7. When set to (the default), the generated ruleset will automatically associate helpers with applications that require them (FTP, IRC, etc.). When configuring your firewall on systems running kernel 3.5 or later, it is recommended that you: Set AUTOHELPERS=No. Either: Modify shorewall6-conntrack (5) to only apply helpers where they are required; or Specify the appropriate helper in the HELPER column in shorewall6-rules (5). The macros for those applications requiring a helper automatically specify the appropriate HELPER where required. AUTOMAKE=[Yes|No] If set, the behavior of the start and restart commands is change; if no files in /etc/shorewall have been changed since the last successful start or restart command, then the compilation step is skipped and the compiled script that executed the last start or restart command is used. The default is AUTOMAKE=No. The setting of the AUTOMAKE option is ignored if the start or restart command includes a directory name (e.g., shorewall6 restart /etc/shorewall.new). BLACKLIST=[{ALL|state[,...]}] where state is one of NEW, ESTABLISHED, RELATED, INVALID,or UNTRACKED. Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY option below. Specifies the connection tracking states that are to be subject to blacklist screening. If neither BLACKLIST nor BLACKLISTNEWONLY are specified then the states subject to blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED. Note: The ESTABLISHED state may not be specified if FASTACCEPT is specified. BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT] This parameter determines the disposition of packets from blacklisted hosts. It may have the value DROP if the packets are to be dropped or REJECT if the packets are to be replied with an ICMP port unreachable reply or a TCP RST (tcp only). If you do not assign a value or if you assign an empty value then DROP is assumed. The setting determines the disposition of packets sent to the blacklog target of shorewall6-blrules(5). BLACKLIST_LOG_LEVEL=[log-level] Formerly named BLACKLIST_LOGLEVEL. This parameter determines if packets from blacklisted hosts are logged and it determines the syslog level that they are to be logged at. Its value is a syslog level (Example: BLACKLIST_LOG_LEVEL=debug). If you do not assign a value or if you assign an empty value then packets from blacklisted hosts are not logged. The setting determines the log level of packets sent to the blacklog target of shorewall6-blrules(5). BLACKLISTNEWONLY={Yes|No} Deprecated in Shorewall 4.5.13 in favor of BLACKLIST above. When set to Yes or yes, blacklists are only consulted for new connections, for packets in the INVALID connection state (such as a TCP SYN,ACK when there has been no corresponding SYN), and for packets that are UNTRACKED due to entries in shorewall6-conntrack(5). This includes entries in the shorewall6-blrules (5) file and in the BLACKLIST section of shorewall6-rules (5). When set to No or no, blacklists are consulted for every packet (will slow down your firewall noticeably if you have large blacklists). If the BLACKLISTNEWONLY option is not set or is set to the empty value then BLACKLISTNEWONLY=No is assumed. BLACKLISTNEWONLY=No is incompatible with FASTACCEPT=Yes. CHAIN_SCRIPTS={Yes|No} Added in Shorewall 4.5.16. Prior to the availability of BEGIN PERL....END PERL in configuration files, the only way to execute a chain-specific script was to create a script file with the same name as the chain and place it in a directory on the CONFIG_PATH. That facility has the drawback that the compiler will attempt to run a non-script file just because it has the same name as a chain. To disable this facility, set CHAIN_SCRIPTS=No. If not specified or specified as the empty value, CHAIN_SCRIPTS=Yes is assumed. CLAMPMSS=[Yes|No|value] This parameter enables the TCP Clamp MSS to PMTU feature of Netfilter and is usually required when your internet connection is through PPPoE or PPTP. If set to Yes or yes, the feature is enabled. If left blank or set to No or no, the feature is not enabled. Important: This option requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel. You may also set CLAMPMSS to a numeric value (e.g., CLAMPMSS=1400). This will set the MSS field in TCP SYN packets going through the firewall to the value that you specify. CLEAR_TC=[Yes|No] If this option is set to No then Shorewall6 won't clear the current traffic control rules during [re]start. This setting is intended for use by people that prefer to configure traffic shaping when the network interfaces come up rather than when the firewall is started. If that is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall6/tcstart file. That way, your traffic shaping rules can still use the “fwmark” classifier based on packet marking defined in shorewall6-tcrules(5). If not specified, CLEAR_TC=No is assumed. If you also run Shorewall and if you have TC_ENABLED=Internal in your shorewall-conf(5), then you will want CLEAR_TC=No in this file. COMPLETE=[Yes|No] Added in Shorewall6 4.4.12. When you set this option to Yes, you are asserting that the configuration is complete so that your set of zones encompasses any hosts that can send or receive traffic to/from/through the firewall. This causes Shorewall6 to omit the rules that catch packets in which the source or destination IP address is outside of any of your zones. Default is No. It is recommended that this option only be set to Yes if: You have defined an interface whose effective physical setting is '+'. That interface is assigned to a zone. You have no CONTINUE policies or rules. CONFIG_PATH=[directory[:directory]...] Specifies where configuration files other than shorewall6.conf may be found. CONFIG_PATH is specifies as a list of directory names separated by colons (":"). When looking for a configuration file other than shorewall6.conf: If the command is "try" or a "<configuration directory>" was specified in the command (e.g., shorewall6 check ./gateway) then the directory given in the command is searched first. Next, each directory in the CONFIG_PATH setting is searched in sequence. If CONFIG_PATH is not given or if it is set to the empty value then the contents of /usr/share/shorewall6/configpath are used. As released from shorewall.net, that file sets the CONFIG_PATH to /etc/shorewall6:/usr/share/shorewall6:/usr/share/shorewall but your particular distribution may set it differently. See the output of shorewall6 show config for the default on your system. DEFER_DNS_RESOLUTION=[Yes|No] Added in Shorewall 4.5.12. When set to 'Yes' (the default), DNS names are validated in the compiler and then passed on to the generated script where they are resolved by ip6tables-restore. This is an advantage if you use AUTOMAKE=Yes and the IP address associated with the DNS name is subject to change. When DEFER_DNS_RESOLUTION=No, DNS names are converted into IP addresses by the compiler. This has the advantage that when AUTOMAKE=Yes the start and restart commands will succeed even if no DNS server is reachable (assuming that the configuration hasn't changed since the compiled script was last generated). DELETE_THEN_ADD={Yes|No} If set to Yes (the default value), entries in the /etc/shorewall6/route_stopped files cause an 'ip rule del' command to be generated in addition to an 'ip rule add' command. Setting this option to No, causes the 'ip rule del' command to be omitted. DONT_LOAD=[module[,module]...] Causes Shorewall6 to not load the listed kernel modules. DYNAMIC_BLACKLIST={Yes|No} Added in Shorewall 4.4.7. When set to No or no, dynamic blacklisting using the shorewall6 drop, shorewall6 reject, shorewall6 logdrop and shorewall6 logreject is disabled. Default is Yes. EXPAND_POLICIES={Yes|No} Normally, when the SOURCE or DEST columns in shorewall-policy(5) contains 'all', a single policy chain is created and the policy is enforced in that chain. For example, if the policy entry is#SOURCE DEST POLICY LOG # LEVEL net all DROP infothen the chain name is 'net2all' which is also the chain named in Shorewall log messages generated as a result of the policy. If EXPAND_POLICIES=Yes, then Shorewall will create a separate chain for each pair of zones covered by the policy. This makes the resulting log messages easier to interpret since the chain in the messages will have a name of the form 'a2b' where 'a' is the SOURCE zone and 'b' is the DEST zone. EXPORTMODULES=[Yes|No] Added in Shorewall 4.4.17. When set to Yes when compiling for use by Shorewall6 Lite (shorewall6 load, shorewall6 reload or shorewall6 export commands), the compiler will copy the modules or helpers file from the administrative system into the script. When set to No or not specified, the compiler will not copy the modules or helpers file from /usr/share/shorewall6 but will copy the found in another location on the CONFIG_PATH. When compiling for direct use by Shorewall6, causes the contents of the local module or helpers file to be copied into the compiled script. When set to No or not set, the compiled script reads the file itself. EXPORTPARAMS={Yes|No} Deprecated beginning with Shorewall 4.4.17. Beginning with Shorewall 4.4.17, the variables set in the 'params' file at compile time are available at run time with EXPORTPARAMS=No. As a consequence, beginning with that version the recommended setting is EXPORTPARAMS=No. It is quite difficult to code a 'params' file that assigns other than constant values such that it works correctly with Shorewall6 Lite. The EXPORTPARAMS option works around this problem. When EXPORTPARAMS=No, the 'params' file is not copied to the compiler output. With EXPORTPARAMS=No, if you need to set environmental variables on the firewall system for use by your extension scripts, then do so in the init extension script. The default is EXPORTPARAMS=Yes which is the recommended setting unless you are running Shorewall6 Lite. FASTACCEPT={Yes|No} Normally, Shorewall6 defers accepting ESTABLISHED/RELATED packets until these packets reach the chain in which the original connection was accepted. So for packets going from the 'loc' zone to the 'net' zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net' chain. If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED packets are accepted early in the INPUT, FORWARD and OUTPUT chains. If you set FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or RELATED sections of shorewall6-rules(5). FASTACCEPT=Yes is incompatible with BLACKLISTNEWONLY=No. FORWARD_CLEAR_MARK={Yes|No} Added in Shorewall 4.4.11 Beta 3. Traditionally, Shorewall has cleared the packet mark in the first rule in the mangle FORWARD chain. This behavior is maintained with the default setting of this option (FORWARD_CLEAR_MARK=Yes). If FORWARD_CLEAR_MARK is set to 'No', packet marks set in the mangle PREROUTING chain are retained in the FORWARD chains. GEOIPDIR=[pathname] Added in Shorewall 4.5.4. Specifies the pathname of the directory containing the GeoIP Match database. See http://www.shorewall.net/ISO-3661.html. If not specified, the default value is /usr/share/xt_geoip/LE which is the default location of the little-endian database. HELPERS=[helper[,helper...]] Added in Shorewall 4.5.7. This option lists the Netfilter application helps that are to be enabled. If not specified, the default is to enable all helpers. Possible values for helper are: amanda ftp h323 irc netbios-ns none - This special value was added in Shorewall 4.5.16 and indicates that no helpers are to be enabled. It also prevents the compiler for probing for helper support; such probing generates messages on the system log of the form "xt_CT: No such helper XXX" where XXX is the helper name. When used, none must be the only helper specified. pptp sane sip snmp tftp When HELPERS is specified on a system running Kernel 3.5.0 or later, automatic association of helpers to connections is disabled. HIGH_ROUTE_MARKS={Yes|No} Deprecated in Shorewall 4.4.26 in favor of PROVIDER_OFFSET. You may set HIGH_ROUTE_MARKS=Yes in to effectively divide the packet mark and connection mark into two mark fields. The width of the fields are determined by the setting of the WIDE_TC_MARKS option. When WIDE_TC_MARKS=No (the default): The MARK field in the providers file must have a value that is less than 65536 and that is a multiple of 256 (using hex representation, the values are 0x0100-0xFF00 with the low-order 8 bits being zero). You may only set those mark values in the PREROUTING chain. Marks used for traffic shaping must still be in the range of 1-255 and may still not be set in the PREROUTING chain. When WIDE_TC_MARKS=Yes: The MARK field in the providers file must have a value that is a multiple of 65536 (using hex representation, the values are 0x010000-0xFF0000 with the low-order 16 bits being zero). You may only set those mark values in the PREROUTING chain. Marks used for traffic shaping must be in the range of 1-16383 and may still not be set in the PREROUTING chain. Regardless of the setting of WIDE_TC_MARKS, when you SAVE or RESTORE in tcrules, only the TC mark value is saved or restored. Shorewall handles saving and restoring the routing (provider) marks. IMPLICIT_CONTINUE={Yes|No} When this option is set to Yes, it causes subzones to be treated differently with respect to policies. Subzones are defined by following their name with ":" and a list of parent zones (in shorewall6-zones(5)). Normally, you want to have a set of special rules for the subzone and if a connection doesn't match any of those subzone-specific rules then you want the parent zone rules and policies to be applied; see shorewall6-nesting(5). With IMPLICIT_CONTINUE=Yes, that happens automatically. If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then subzones are not subject to this special treatment. With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden by including an explicit policy (one that does not specify "all" in either the SOURCE or the DEST columns). INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE] Added in Shorewall 4.5.13. Shorewall has traditionally passed INVALID packets through the NEW section of shorewall-rules (5). When a packet in INVALID state fails to match any rule in the INVALID section, the packet is disposed of based on this setting. The default value is CONTINUE for compatibility with earlier versions. INVALID_LOG_LEVEL=log-level Added in Shorewall 4.5.13. Packets in the INVALID state that do not match any rule in the INVALID section of shorewall-rules (5) are logged at this level. The default value is empty which means no logging is performed. IP=[pathname] If specified, gives the pathname of the 'ip' executable. If not specified, 'ip' is assumed and the utility will be located using the current PATH setting. IP_FORWARDING=[On|Off|Keep] This rather useless parameter determines whether Shorewall6 enables or disables IPV6 Packet Forwarding on all interfaces (/proc/sys/net/ipv6/config/all/forwarding). Possible values are: On or on packet forwarding will be enabled. Off or off packet forwarding will be disabled. Keep or keep Shorewall6 will neither enable nor disable packet forwarding
If this variable is not set or is given an empty value (IP_FORWARD="") then IP_FORWARD=On is assumed.
IP6TABLES=[pathname] This parameter names the ip6tables executable to be used by Shorewall6. If not specified or if specified as a null value, then the ip6tables executable located using the PATH option is used. Regardless of how the ip6tables utility is located (specified via IP6TABLES= or located via PATH), Shorewall6 uses the ip6tables-restore and ip6tables-save utilities from that same directory. IPSET=[pathname] If specified, gives the pathname of the 'ipset' executable. If not specified, 'ipset' is assumed and the utility will be located using the current PATH setting. IPSET_WARNINGS={Yes|No} Added in Shorewall 4.5.2. Default is Yes. When set, causes the rules compiler to issue a warning when: The compiler is being run by root and an ipset specified in the configuration does not exists. Only one warning is issued for each missing ipset. When [src] is specified in a destination column and when [dst] is specified in a source column. KEEP_RT_TABLES={Yes|No} When set to , this option prevents scripts generated by Shorewall6 from altering the /etc/iproute2/rt_tables database when there are entries in /etc/shorewall6/providers. If you set this option to while Shorewall6 (Shorewall6-lite) is running, you should remove the file /var/lib/shorewall6/rt_tables (/var/lib/shorewall6-lite/rt_tables) before your next stop, refresh, restore on restart command. The default is KEEP_RT_TABLES=No. LEGACY_FASTSTART={Yes|No} Added in Shorewall6 4.4.20. If not specified, the default is Yes which preserves the legacy behavior of start -f (the modification times of the files in /etc/shorewall6 are compare with that of /var/lib/shorewall6/restore). If set to No, then the times are compared with that of /var/lib/shorewall6/firewall, which is consistent with the way that restart -f works. LOAD_HELPERS_ONLY={Yes|No} Added in Shorewall 4.4.7. When set to Yes, restricts the set of modules loaded by shorewall to those listed in /var/lib/shorewall6/helpers and those that are actually used. When not set, or set to the empty value, LOAD_HELPERS_ONLY=No is assumed. LOCKFILE=[pathname] Specifies the name of the Shorewall6 lock file, used to prevent simultaneous state-changing commands. If not specified, ${VARDIR}/shorewall6/lock is assumed (${VARDIR} is normally /var/lib but can be changed when Shorewall-core is installed -- see the output of shorewall6 show vardir). LOG_VERBOSITY=[number] This option controls the amount of information logged to the file specified in the STARTUP_LOG option. Values are: -1 - Logging is disabled 0 - Silent. Only error messages are logged. 1 - Major progress messages logged. 2 - All progress messages logged If not specified, then -1 is assumed. LOGALLNEW=[log-level] This option is intended for use as a debugging aid. When set to a log level, this option causes Shorewall6 to generate a logging rule as the first rule in each builtin chain. The table name is used as the chain name in the log prefix. The chain name is used as the target in the log prefix.
For example, using the default LOGFORMAT, the log prefix for logging from the nat table's PREROUTING chain is: Shorewall:nat:PREROUTING To help insure that all packets in the NEW state are logged, rate limiting (LOGBURST and LOGRATE) should be disabled when using LOGALLNEW. Use LOGALLNEW at your own risk; it may cause high CPU and disk utilization and you may not be able to control your firewall after you enable this option. Do not use this option if the resulting log messages will be sent to another system.
LOGFILE=[pathname] This parameter tells the /sbin/shorewall6 program where to look for Shorewall6 messages when processing the dump, logwatch, show log, and hits commands. If not assigned or if assigned an empty value, /var/log/messages is assumed. LOGFORMAT=["formattemplate"] The value of this variable generate the --log-prefix setting for Shorewall6 logging rules. It contains a “printf” formatting template which accepts three arguments (the chain name, logging rule number (optional) and the disposition). To use LOGFORMAT with fireparse, set it as: LOGFORMAT="fp=%s:%d a=%s " If the LOGFORMAT value contains the substring “%d” then the logging rule number is calculated and formatted in that position; if that substring is not included then the rule number is not included. If not supplied or supplied as empty (LOGFORMAT="") then “Shorewall6:%s:%s:” is assumed. The setting of LOGFORMAT has an effect of the permitted length of zone names. See shorewall6-zones (5). LOGLIMIT=[[{s|d}:]rate/{sec|min|hour|day}[:burst]] Added in Shorewall 4.4.12. Limits the logging rate, either overall, or by source or destination IP address. If the value starts with 's:' then logging is limited per source IP. If the value starts with 'd:', then logging is limited per destination IP. Otherwise, the overall logging rate is limited. If burst is not specified, then a value of 5 is assumed. LOGBURST=[burst] Deprecated in Shorewall 4.4.12. LOGRATE=[rate/{minute|second}] As of Shorewall 4.4.12, these parameters are Deprecated. These parameters set the match rate and initial burst size for logged packets. Please see ip6tables(8) for a description of the behavior of these parameters (the ip6tables option --limit is set by LOGRATE and --limit-burst is set by LOGBURST). If both parameters are set empty, no rate-limiting will occur. If you supply one of these, then you should also supply the other. Example: LOGRATE=10/minute LOGBURST=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, 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. LOGTAGONLY=[Yes|No] Using the default LOGFORMAT, chain names may not exceed 11 characters or truncation of the log prefix may occur. Longer chain names may be used with log tags if you set LOGTAGONLY=Yes. With LOGTAGONLY=Yes, if a log tag is specified then the tag is included in the log prefix in place of the chain name. Beginning with Shorewall 4.5.12, when LOGTAGONLY=Yes, you have more control over the generated log prefix. Beginning with that release, the tag is interpreted as a chain name and a disposition separated by a comma. So this rule: #ACTION SOURCE DEST LOG:info:foo,bar net fw would generate the following log prefix when using the default LOGFORMAT setting: Shorewall:foo:bar: Similarly, #ACTION SOURCE DEST LOG:info:,bar net fw would generate Shorewall:net2fw:bar: MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT] Determines the disposition of connections requests that fail MAC Verification and must have the value ACCEPT (accept the connection request anyway), REJECT (reject the connection request) or DROP (ignore the connection request). If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed. A_DROP and A_REJECT are audited versions of DROP and REJECT respectively and were added in Shorewall 4.4.20. They require AUDIT_TARGET in the kernel and ip6tables. MACLIST_LOG_LEVEL=[log-level] Determines the syslog level for logging connection requests that fail MAC Verification. The value must be a valid syslogd log level. If you don't want to log these connection requests, set to the empty value (e.g., MACLIST_LOG_LEVEL=""). MACLIST_TABLE=[filter|mangle] Normally, MAC verification occurs in the filter table (INPUT and FORWARD) chains. When forwarding a packet from an interface with MAC verification to a bridge interface, that doesn't work. This problem can be worked around by setting MACLIST_TABLE=mangle which will cause Mac verification to occur out of the PREROUTING chain. Because REJECT isn't available in that environment, you may not specify MACLIST_DISPOSITION=REJECT with MACLIST_TABLE=mangle. MACLIST_TTL=[number] The performance of configurations with a large numbers of entries in shorewall-maclist(5) can be improved by setting the MACLIST_TTL variable in shorewall.conf(5). If your iptables and kernel support the "Recent Match" (see the output of "shorewall check" near the top), you can cache the results of a 'maclist' file lookup and thus reduce the overhead associated with MAC Verification. When a new connection arrives from a 'maclist' interface, the packet passes through then list of entries for that interface in shorewall-maclist(5). If there is a match then the source IP address is added to the 'Recent' set for that interface. Subsequent connection attempts from that IP address occurring within $MACLIST_TTL seconds will be accepted without having to scan all of the entries. After $MACLIST_TTL from the first accepted connection request from an IP address, the next connection request from that IP address will be checked against the entire list. If MACLIST_TTL is not specified or is specified as empty (e.g, MACLIST_TTL="" or is specified as zero then 'maclist' lookups will not be cached). MANGLE_ENABLED=[Yes|No] Determines whether Shorewall will generate rules in the Netfilter mangle table. Setting MANGLE_ENABLED=No disables all Shorewall features that require the mangle table. The default is MANGLE_ENABLED=Yes. MARK_IN_FORWARD_CHAIN=[Yes|No] If your kernel has a FORWARD chain in the mangle table, you may set MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the tcrules file to occur in that chain rather than in the PREROUTING chain. This permits you to mark inbound traffic based on its destination address when DNAT is in use. To determine if your kernel has a FORWARD chain in the mangle table, use the /sbin/shorewall6 show mangle command; if a FORWARD chain is displayed then your kernel will support this option. If this option is not specified or if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed. MASK_BITS=[number] Added in Shorewall 4.4.26. Number of bits on the right of the 32-bit packet mark to be masked when clearing the traffic shaping mark. Must be >= TC_BITS and <= PROVIDER_OFFSET (if PROVIDER_OFFSET > 0). Default value and the default values of the other mark layout options is determined as follows: Default Packet Mark Layout 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
MODULE_SUFFIX=["extension ..."] The value of this option determines the possible file extensions of kernel modules. The default value is "ko ko.gz o o.gz gz". MODULESDIR=[pathname[:pathname]...] This parameter specifies the directory/directories where your kernel netfilter modules may be found. If you leave the variable empty, Shorewall6 will supply "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter:/lib/modules/`uname -r`/kernel/net/ipv4/netfilter". MUTEX_TIMEOUT=[seconds] The value of this variable determines the number of seconds that programs will wait for exclusive access to the Shorewall6 lock file. After the number of seconds corresponding to the value of this variable, programs will assume that the last program to hold the lock died without releasing the lock. If not set or set to the empty value, a value of 60 (60 seconds) is assumed. An appropriate value for this parameter would be twice the length of time that it takes your firewall system to process a shorewall6 restart command. NFACCT=[pathname] Added in Shorewall 4.5.7. Specifies the pathname of the nfacct utility. If not specified, Shorewall will use the PATH setting to find the program. OPTIMIZE=[value] The specified value enables certain optimizations. Each optimization category is associated with a power of two. To enable multiple optimization categories, simply add their corresponding numbers together. Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All to enable all optimization categories, and you may also specify OPTIMIZE=None to disable optimization. Optimization category 1 - Traditionally, Shorewall has created rules for the complete matrix of host groups defined by the zones, interfaces and hosts files. Any traffic that didn't correspond to an element of that matrix was rejected in one of the built-in chains. When the matrix is sparse, this results in lots of largely useless rules. These extra rules can be eliminated by setting the 1 bit in OPTIMIZE. The 1 bit setting also controls the suppression of redundant wildcard rules (those specifying "all" in the SOURCE or DEST column). A wildcard rule is considered to be redundant when it has the same ACTION and Log Level as the applicable policy. Optimization level 1 is ignored when optimization level 4 is also selected, since level 4 performs similar optimizations in a more robust way. Optimization category 2 - Added in Shorewall 4.4.7. When set, suppresses superfluous ACCEPT rules in a policy chain that implements an ACCEPT policy. Any ACCEPT rules that immediately precede the final blanket ACCEPT rule in the chain are now omitted. Optimization category 4 - Added in Shorewall 4.4.7. When set, causes short chains (those with less than 2 rules) to be optimized away. The following chains are excluded from optimization: accounting chains (unless OPTIMIZE_ACCOUNTING=Yes) action chains (user-defined) 'blacklst' chain dynamic Additionally: If a built-in chain has a single rule that branches to a second chain, then the rules from the second chain are moved to the built-in chain and the target chain is omitted. Chains with no references are deleted. Accounting chains are subject to optimization if the OPTIMIZE_ACCOUNTING option is set to 'Yes'. If a chain ends with an unconditional branch to a second chain (other than to 'reject'), then the branch is deleted from the first chain and the rules from the second chain are appended to it. An additional optimization was added in Shorewall 4.5.4. If the last rule in a chain is an unqualified jump to a simple target, then all immediately preceding rules with the same simple target are omitted. For example, consider this chain: -A fw-net -p udp --dport 67:68 -j ACCEPT -A fw-net -p udp --sport 1194 -j ACCEPT -A fw-net -p 41 -j ACCEPT -A fw-net -j ACCEPT Since all of the rules are jumps to the simple target ACCEPT, this chain is totally optimized away and jumps to the chain are replace with jumps to ACCEPT. Optimization category 8 - Added in Shorewall 4.4.9. When set, causes chains with identical rules to be collapsed into a single chain. Optimization category 16 - Added in Shorewall 4.4.26. When set, causes sequences of compatible rules to be combined into a single rule. Rules are considered compatible if they differ only in their destination ports and comments. A sequence of compatible rules is often generated when macros are invoked in sequence. The ability to combine adjacent rules is limited by two factors: Destination port lists may only be combined up to a maximum of 15 ports, where a port-pair counts as two ports. Rules may only be combined until the length of their concatenated comment reaches 255 characters. When either of these limits would be exceeded, the current combined rule is emitted and the compiler attempts to combine rules beginning with the one that would have exceeded the limit. Adjacent combined comments are separated by ', '. Empty comments at the front of a group of combined comments are replaced by 'Others and'. Empty comments at the end of a group of combined comments are replaced by 'and others'. Beginning in Shorewall 4.5.10, this option also suppresses duplicate adjacent rules and duplicate non-adjacent rules that don't include mark, connmark, dscp, ecn, set, tos or u32 matches. Example 1: Rules with comments "FOO", <empty> and "BAR" would result in the combined comment "FOO and others, BAR". Example 2: Rules with comments <empty>, "FOO" and "BAR" would result in the combined comment "Others and FOO, BAR". Note: Optimize level 16 requires "Extended Multi-port Match" in your iptables and kernel. The default value is zero which disables all optimizations. OPTIMIZE_ACCOUNTING=[Yes|No] Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting changes are subject to optimization (OPTIMIZE=4,5,6 or 7). If not specified or set to the empty value, OPTIMIZE_ACCOUNTING=No is assumed. PATH=pathname[:pathname]... Determines the order in which Shorewall6 searches directories for executable files. PERL=pathname Added in Shorewall 4.4.11 RC1. Specifies the path name of the Perl executable. Default is /usr/bin/perl. If the pathname specified by this option does not exist or the named file is not executable, then Shorewall6 falls back to /usr/bin/perl/ PROVIDER_BITS=[number] Added in Shorewall 4.4.26. The number of bits in the 32-bit packet mark to be used for provider numbers. May be zero. See MASK_BITS above for default value. PROVIDER_OFFSET=[number] Added in Shorewall 4.4.26. The offset from the right (low-order end) of the provider number field in the 32-bit packet mark. If non-zero, must be >= TC_BITS (Shorewall automatically adjusts PROVIDER_OFFSET's value). PROVIDER_OFFSET + PROVIDER_BITS + ZONE_BITS must be < 32. See MASK_BITS above for default value. RCP_COMMAND="command" RSH_COMMAND="command" Earlier generations of Shorewall6 Lite required that remote root login via ssh be enabled in order to use the load and reload commands. Beginning with release 3.9.5, you may define an alternative means for accessing the remote firewall system. In that release, two new options were added to shorewall6.conf: RSH_COMMAND RCP_COMMAND The default values for these are as follows: RSH_COMMAND: ssh ${root}@${system} ${command} RCP_COMMAND: scp ${files} ${root}@${system}:${destination} Shell variables that will be set when the commands are invoked are as follows: root - root user. Normally but may be overridden using the '-r' option. system - The name/IP address of the remote firewall system. command - For RSH_COMMAND, the command to be executed on the firewall system. files - For RCP_COMMAND, a space-separated list of files to be copied to the remote firewall system. destination - The directory on the remote system that the files are to be copied into. RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE] Added in Shorewall 4.4.27. Shorewall has traditionally ACCEPTed RELATED packets that don't match any rule in the RELATED section of shorewall6-rules (5). Concern about the safety of this practice resulted in the addition of this option. When a packet in RELATED state fails to match any rule in the RELATED section, the packet is disposed of based on this setting. The default value is ACCEPT for compatibility with earlier versions. RELATED_LOG_LEVEL=log-level Added in Shorewall 4.4.27. Packets in the related state that do not match any rule in the RELATED section of shorewall6-rules (5) are logged at this level. The default value is empty which means no logging is performed. REJECT_ACTION=action Added in Shorewall 4.5.21. When a REJECT target is specified, Shorewall normally handles the response as follows: If the destination address of the packet is a broadcast or multicast address, the packet is dropped. if the protocol is ICMP (58) then the packet is dropped. if the protocol is TCP (6) then the packet is rejected with an RST. if the protocol is UDP (17) then the packet is rejected with an 'port-unreachable' ICMP (ICMP6). if the protocol is ICMP (1) then the packet is rejected with a 'addr-unreachable' ICMP. otherwise, the packet is rejected with a 'adm-prohibited' ICMP. You can modify this behavior by implementing your own action that handles REJECT and specifying it's name in this option. The nolog and inline options will automatically be assumed for the specified action. The following action implements the standard behavior: ?format 2 #TARGET SOURCE DEST PROTO Broadcast(DROP) - - - DROP - - 2 INLINE - - 6 ; -j REJECT --reject-with tcp-reset ?if __ENHANCED_REJECT INLINE - - 17 ; -j REJECT ?if __IPV4 INLINE - - 1 ; -j REJECT --reject-with icmp-host-unreachable INLINE - - - ; -j REJECT --reject-with icmp-host-prohibited ?else INLINE - - 58 ; -j REJECT --reject-with icmp6-addr-unreachable INLINE - - - ; -j REJECT --reject-with icmp6-adm-prohibited ?endif ?else INLINE - - - ; -j REJECT ?endif REQUIRE_INTERFACE=[Yes|No] Added in Shorewall 4.4.10. The default is No. If set to Yes, at least one optional interface must be up in order for the firewall to be in the started state. Intended to be used with the Shorewall Init Package. RESTORE_ROUTEMARKS=[Yes|No] Added in Shorewall 4.5.9. When set to Yes (the default), provider marks are restored unconditionally at the top of the mangle OUTPUT and PREROUTING chains, even if the saved mark is zero. When this option is set to No, the mark is restored even when it is zero. If you have problems with IPSEC ESP packets not being routed correctly on output, try setting this option to No. RESTOREFILE=filename Specifies the simple name of a file in /var/lib/shorewall6 to be used as the default restore script in the shorewall6 save, shorewall6 restore, shorewall6 forget and shorewall6 -f start commands. RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT] Added in Shorewall 4.5.7. Determines the disposition of packets entering from interfaces with the option (see shorewall-interfaces(5)). Packets disposed of by this option are those whose response packets would not be sent through the same interface receiving the packet. RPFILTER_LOG_LEVEL=log-level Added in shorewall 4.5.7. Determines the logging of packets disposed via the RPFILTER_DISPOSITION. The default value is . SHOREWALL_SHELL=[pathname] This option is used to specify the shell program to be used to interpret the compiled script. If not specified or specified as a null value, /bin/sh is assumed. Using a light-weight shell such as ash or dash can significantly improve performance. SMURF_DISPOSITION=[DROP|A_DROP] Added in Shorewall 4.4.20. The default setting is DROP which causes smurf packets (see the nosmurfs option in shorewall-interfaces(5)) to be dropped. A_DROP causes the packets to be audited prior to being dropped and requires AUDIT_TARGET support in the kernel and ip6tables. SMURF_LOG_LEVEL=[log-level] Specifies the logging level for smurf packets (see the nosmurfs option in shorewall6-interfaces(5)). If set to the empty value ( SMURF_LOG_LEVEL="" ) then smurfs are not logged. SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT] Added in Shorewall 4.4.20. Determines the disposition of packets matching the option (see shorewall6-interfaces(5)) and of hairpin packets on interfaces without the option. Hairpin packets are packets that are routed out of the same interface that they arrived on. interfaces without the routeback option. SFILTER_LOG_LEVEL=log-level Added on Shorewall 4.4.20. Determines the logging of packets matching the option (see shorewall6-interfaces(5)) and of hairpin packets on interfaces without the option. Hairpin packets are packets that are routed out of the same interface that they arrived on. interfaces without the routeback option. The default is . If you don't wish for these packets to be logged, use SFILTER_LOG_LEVEL=none. STARTUP_ENABLED={Yes|No} Determines if Shorewall6 is allowed to start. As released from shorewall.net, this option is set to No. When set to Yes or yes, Shorewall6 may be started. Used as a guard against Shorewall6 being accidentally started before it has been configured. STARTUP_LOG=[pathname] If specified, determines where Shorewall6 will log the details of each start, restart and refresh command. Logging verbosity is determined by the setting of LOG_VERBOSITY above. SUBSYSLOCK=[pathname] This parameter should be set to the name of a file that the firewall should create if it starts successfully and remove when it stops. Creating and removing this file allows Shorewall6 to work with your distribution's initscripts. For RedHat, this should be set to /var/lock/subsys/shorewall6. For Debian, the value is /var/lock/shorewall6 and in LEAF it is /var/run/shorewall. TC=[pathname] If specified, gives the pathname of the 'tc' executable. If not specified, 'tc' is assumed and the utility will be located using the current PATH setting. TC_BITS=[number] Added in Shorewall 4.4.26. The number of bits at the low end of the 32-bit packet mark to be used for traffic shaping marking. May be zero. See MASK_BITS above for default value. TC_ENABLED=[Yes|No|Internal|Shared] If you say Yes or yes here, Shorewall6 will use a script that you supply to configure traffic shaping. The script must be named 'tcstart' and must be placed in a directory on your CONFIG_PATH. If you say No or no then traffic shaping is not enabled. If you set TC_ENABLED=Internal or internal or leave the option empty then Shorewall6 will use its builtin traffic shaper (tc4shorewall6 written by Arne Bernin. Beginning with Shorewall 4.4.15, if you set TC_ENABLED=Shared or shared, then you should create symbolic links from your Shorewall6 configuration directory (normally /etc/shorewall6/) to your Shorewall tcdevices and tcclasses files. This allows the compiler to have access to your Shorewall traffic shaping configuration so that it can validate CLASSIFY rules in shorewall6-tcrules (5). If you also run Shorewall and if you have TC_ENABLED=Internal in your shorewall-conf(5), then you will want TC_ENABLED=No or TC_ENABLED=Shared in this file. TC_EXPERT={Yes|No} Normally, Shorewall6 tries to protect users from themselves by preventing PREROUTING and OUTPUT tcrules from being applied to packets that have been marked by the 'track' option in shorewall6-providers(5). If you know what you are doing, you can set TC_EXPERT=Yes and Shorewall6 will not include these cautionary checks. TC_PRIOMAP=map Added in Shorewall 4.4.6. Determines the mapping of a packet's TOS field to priority bands. See shorewall6-tcpri(5). The map consists of 16 space-separated digits with values 1, 2 or 3. A value of 1 corresponds to Linux priority 0, 2 to Linux priority 1, and 3 to Linux Priority 2. The first entry gives the priority of TOS value 0, the second of TOS value 1, and so on. See tc-prio(8) for additional information. The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2 2 2". TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT] Determines the disposition of TCP packets that fail the checks enabled by the tcpflags interface option (see shorewall6-interfaces(5)) and must have a value of ACCEPT (accept the packet), REJECT (send an RST response) or DROP (ignore the packet). If not set or if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed. TCP_FLAGS_LOG_LEVEL=[log-level] Determines the syslog level for logging packets that fail the checks enabled by the tcpflags interface option. The value must be a valid syslogd log level. If you don't want to log these packets, set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL=""). TRACK_PROVIDERS={Yes|No} Added in Shorewall 4.4.3. When set to Yes, causes the option to be assumed on all providers defined in shorewall6-providers(5). May be overridden on an individual provider through use of the option. The default value is 'No'. Beginning in Shorewall 4.4.6, setting this option to 'Yes' also simplifies PREROUTING rules in shorewall6-tcrules(5). Previously, when TC_EXPERT=No, packets arriving through 'tracked' provider interfaces were unconditionally passed to the PREROUTING tcrules. This was done so that tcrules could reset the packet mark to zero, thus allowing the packet to be routed using the 'main' routing table. Using the main table allowed dynamic routes (such as those added for VPNs) to be effective. The shorewall6-rtrules(5) file was created to provide a better alternative to clearing the packet mark. As a consequence, passing these packets to PREROUTING complicates things without providing any real benefit. Beginning with Shorewall 4.4.6, when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving through 'tracked' interfaces will not be passed to the PREROUTING rules. Since TRACK_PROVIDERS was just introduced in 4.4.3, this change should be transparent to most, if not all, users. TRACK_RULES={Yes|No} Added in Shorewall 4.5.20. If set to Yes, causes the compiler to add a comment to iptables rules to indicate the file name and line number of the configuration entry that generated the rule. If set to No (the default), then no such comments are added. Setting this option to Yes requires the Comments capability in ip6tables and kernel. UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE] Added in Shorewall 4.5.13. Shorewall has traditionally passed UNTRACKED packets through the NEW section of shorewall6-rules (5). When a packet in UNTRACKED state fails to match any rule in the UNTRACKED section, the packet is disposed of based on this setting. The default value is CONTINUE for compatibility with earlier versions. UNTRACKED_LOG_LEVEL=log-level Added in Shorewall 4.5.13. Packets in the UNTRACKED state that do not match any rule in the UNTRACKED section of shorewall-rules (5) are logged at this level. The default value is empty which means no logging is performed. USE_DEFAULT_RT=[Yes|No] Added in Shorewall6 4.4.25. When set to 'Yes', this option causes the Shorewall6 multi-ISP feature to create a different set of routing rules which are resilient to changes in the main routing table. Such changes can occur for a number of reasons, VPNs going up and down being an example. The idea is to send packets through the main table prior to applying any of the Shorewall6-generated routing rules. So changes to the main table will affect the routing of packets by default. When USE_DEFAULT_RT=Yes: Both the DUPLICATE and the COPY columns in shorewall6-providers(5) file must remain empty (or contain "-"). The default route is added to the the 'default' table rather than to the main table. balance is assumed unless loose is specified. Packets are sent through the main routing table by a rule with priority 999. In shorewall6-routing_rules(5), the range 1-998 may be used for inserting rules that bypass the main table. All provider gateways must be specified explicitly in the GATEWAY column. detect may not be specified. You should disable all default route management outside of Shorewall6. If a default route is added to the main table while Shorewall is started, then all policy routing will stop working (except for those routing rules in the priority range 1-998). If USE_DEFAULT_RT is not set or if it is set to the empty string then USE_DEFAULT_RT=No is assumed. USE_PHYSICAL_NAMES=[Yes|No] Added in Shorewall 4.4.27. Normally, when Shorewall creates a Netfilter chain that relates to an interface, it uses the interface's logical name as the base of the chain name. For example, if the logical name for an interface is OAKLAND, then the input chain for traffic arriving on that interface would be 'OAKLAND_in'. If this option is set to Yes, then the physical name of the interface will be used the base of the chain name. USE_RT_NAMES=[Yes|No] Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will use routing table (provider) names in the generated script rather than table numbers. When set to 'No' (the default), routing table numbers will be used. If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you must insure that all of your providers have entries in /etc/iproute2/rt_tables as well as the following entries: 255 local 254 main 253 default 250 balance 0 unspec Without these entries, the firewall will fail to start. VERBOSITY=[number] Shorewall6 has traditionally been very noisy (produced lots of output). You may set the default level of verbosity using the VERBOSITY OPTION. Values are: 0 - Silent. You may make it more verbose using the -v option 1 - Major progress messages displayed 2 - All progress messages displayed (pre Shorewall6-3.2.0 behavior) If not specified, then 2 is assumed. WARNOLDCAPVERSION=[Yes|No] Added in Shorewall 4.5.12. When set to Yes (the default), the compiler issues a warning when it finds a capabilities file that doesn't specify all of the capabilities supported by the compiler. When WARNOLDCAPVERSION is set to No, no warning is issued. WIDE_TC_MARKS={Yes|No} Deprecated in Shorewall 4.4.26 in favor of TC_BITS and MASK_BITS. When set to No (the default), traffic shaping marks are 8 bytes wide (possible values are 1-255). When WIDE_TC_MARKS=Yes, traffic shaping marks are 14 bytes wide (values 1-16383). The setting of WIDE_TC_MARKS also has an effect on the HIGH_ROUTE_MARKS option (see above). ZONE_BITS=[number] Added in Shorewall 4.4.26. When non-zero, enables automatic packet marking by source zone and determines the number of bits in the 32-bit packet mark to be used for the zone mark. Default value is 0. ZONE2ZONE={|} Added in Shorewall 4.4.4. This option determines how Shorewall constructs chain names involving zone names and/or 'all'. The default is '2' (e.g., fw2net).
FILES /etc/shorewall6/shorewall6.conf See ALSO shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-ipsec(5), shorewall6-maclist(5), shorewall6-masq(5), shorewall6-nat(5), shorewall6-netmap(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-proxyarp(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-rules.xml0000644000175000017500000021236112222401136023042 0ustar teastepteastep shorewall6-rules 5 rules Shorewall6 rules file /etc/shorewall6/rules Description Entries in this file govern connection establishment by defining exceptions to the policies laid out in shorewall6-policy(5). By default, subsequent requests and responses are automatically allowed using connection tracking. For any particular (source,dest) pair of zones, the rules are evaluated in the order in which they appear in this file and the first terminating match is the one that determines the disposition of the request. All rules are terminating except LOG and QUEUE rules. The rules file is divided into sections. Each section is introduced by a "Section Header" which is a line beginning with SECTION and followed by the section name. Sections are as follows and must appear in the order listed: ALL This section was added in Shorewall 4.4.23. rules in this section are applied, regardless of the connection tracking state of the packet. ESTABLISHED Packets in the ESTABLISHED state are processed by rules in this section. The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG and QUEUE There is an implicit ACCEPT rule inserted at the end of this section. RELATED Packets in the RELATED state are processed by rules in this section. The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG and QUEUE There is an implicit rule added at the end of this section that invokes the RELATED_DISPOSITION (shorewall6.conf(5)). INVALID Added in Shorewall 4.5.13. Packets in the INVALID state are processed by rules in this section. The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG and QUEUE. There is an implicit rule added at the end of this section that invokes the INVALID_DISPOSITION (shorewall6.conf(5)). UNTRACKED Added in Shorewall 4.5.13. Packets in the UNTRACKED state are processed by rules in this section. The only Actions allowed in this section are ACCEPT, DROP, REJECT, LOG and QUEUE. There is an implicit rule added at the end of this section that invokes the UNTRACKED_DISPOSITION (shorewall6.conf(5)). NEW Packets in the NEW, INVALID and UNTRACKED states are processed by rules in this section. If you are not familiar with Netfilter to the point where you are comfortable with the differences between the various connection tracking states, then it is suggested that you omit the ESTABLISHED and RELATED sections and place all of your rules in the NEW section (That's after the line that reads SECTION NEW'). If you specify FASTACCEPT=Yes in shorewall6.conf(5) then the ESTABLISHED and RELATED sections must be empty. An except is made if you are running Shorewall 4.4.27 or later and you have specified a non-default value for RELATED_DISPOSITION or RELATED_LOG_LEVEL. In that case, you may have rules in the RELATED section of this file. You may omit any section that you don't need. If no Section Headers appear in the file then all rules are assumed to be in the NEW section. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ACTION - target[:{log-level|none}[!][:tag]] Specifies the action to be taken if the connection request matches the rule. target must be one of the following. ACCEPT Allow the connection request. ACCEPT+ like ACCEPT but also excludes the connection from any subsequent matching DNAT[-] or REDIRECT[-] rules. Requires Shorewall 4.5.14 or later. ACCEPT! like ACCEPT but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall6.conf(5). action The name of an action declared in shorewall6-actions(5) or in /usr/share/shorewall/actions.std. ADD(ipset:flags) Added in Shorewall 4.4.12. Causes addresses and/or port numbers to be added to the named ipset. The flags specify the address or tuple to be added to the set and must match the type of ipset involved. For example, for an iphash ipset, either the SOURCE or DESTINATION address can be added using flags src or dst respectively (see the -A command in ipset (8)). ADD is non-terminating. Even if a packet matches the rule, it is passed on to the next rule. AUDIT[(accept|drop|reject)] Added in Shorewall 4.5.10. Audits the packet with the specified type; if the type is omitted, then is assumed. Require AUDIT_TARGET support in the kernel and iptables. A_ACCEPT, and A_ACCEPT! Added in Shorewall 4.4.20. Audited versions of ACCEPT and ACCEPT! respectively. Require AUDIT_TARGET support in the kernel and iptables. A_DROP and A_DROP! Added in Shorewall 4.4.20. Audited versions of DROP and DROP! respectively. Require AUDIT_TARGET support in the kernel and iptables. A_REJECT AND A_REJECT! Added in Shorewall 4.4.20. Audited versions of REJECT and REJECT! respectively. Require AUDIT_TARGET support in the kernel and iptables. [?]COMMENT the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries. The comment will appear delimited by "/* ... */" in the output of "shorewall show <chain>". To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. CONTINUE For experts only. Do not process any of the following rules for this (source zone,destination zone). If the source and/or destination IP address falls into a zone defined later in shorewall6-zones(5) or in a parent zone of the source or destination zones, then this connection request will be passed to the rules defined for that (those) zone(s). See shorewall6-nesting(5) for additional information. CONTINUE! like CONTINUE but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall6.conf(5). COUNT Simply increment the rule's packet and byte count and pass the packet to the next rule. DEL(ipset:flags) Added in Shorewall 4.4.12. Causes an entry to be deleted from the named ipset. The flags specify the address or tuple to be deleted from the set and must match the type of ipset involved. For example, for an iphash ipset, either the SOURCE or DESTINATION address can be deleted using flags src or dst respectively (see the -D command in ipset (8)). DEL is non-terminating. Even if a packet matches the rule, it is passed on to the next rule. DNAT Forward the request to another system (and optionally another port). Requires Shorewall 4.5.14 or later. DNAT- Advanced users only. Like DNAT but only generates the DNAT iptables rule and not the companion ACCEPT rule. Requires Shorewall 4.5.14 or later. DROP Ignore the request. DROP! like DROP but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall6.conf(5). HELPER Added in Shorewall 4.5.7. This action requires that the HELPER column contains the name of the Netfilter helper to be associated with connections matching this connection. May only be specified in the NEW section and is useful for being able to specify a helper when the applicable policy is ACCEPT. No destination zone should be specified in HELPER rules. INLINE[(action)] Added in Shorewall 4.5.16. This action allows you to construct most of the rule yourself using ip6tables syntax. The part that you specify must follow a semicolon (';') and is completely free-form. If the target of the rule (the part following 'j') is something that Shorewall supports in the ACTION column, then you may enclose it in parentheses (e.g., INLINE(ACCEPT)). Otherwise, you can include it after the semicolon. In this case, you must declare the target as a builtin action in shorewall6-actions(5). Some considerations when using INLINE: The , , , , , , and state match ( or ) matches will always appear in the front of the rule in that order. When multiple matches are specified, the compiler will keep them in the order in which they appear (excluding the above listed ones), but they will not necessarily be at the end of the generated rule. For example, if addresses are specified in the SOURCE and/or DEST columns, their generated matches will appear after those specified using ';'. LOG:level Simply log the packet and continue with the next rule. macro[(macrotarget)] The name of a macro defined in a file named macro.macro. If the macro accepts an action parameter (Look at the macro source to see if it has PARAM in the TARGET column) then the macro name is followed by the parenthesized macrotarget (ACCEPT, DROP, REJECT, ...) to be substituted for the parameter. Example: FTP(ACCEPT). The older syntax where the macro name and the target are separated by a slash (e.g. FTP/ACCEPT) is still allowed but is deprecated. NFLOG[(nflog-parameters)] Added in Shorewall 4.5.9.3. Queues matching packets to a back end logging daemon via a netlink socket then continues to the next rule. See http://www.shorewall.net/shorewall_logging.html. Similar to LOG:NFLOG[(nflog-parameters)], except that the log level is not changed when this ACTION is used in an action or macro and the invocation of that action or macro specifies a log level. NFQUEUE[(queuenumber)] Queues the packet to a user-space application using the nfnetlink_queue mechanism. If a queuenumber is not specified, queue zero (0) is assumed. NFQUEUE![(queuenumber)] like NFQUEUE but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall6.conf(5). NONAT Excludes the connection from any subsequent DNAT[-] or REDIRECT[-] rules but doesn't generate a rule to accept the traffic. Requires Shorewall 4.5.14 or later. QUEUE Queue the packet to a user-space application such as ftwall (http://p2pwall.sf.net). The application may reinsert the packet for further processing. QUEUE! like QUEUE but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall6.conf(5). REDIRECT Redirect the request to a server running on the firewall. Requires Shorewall 4.5.14 or later. REDIRECT- Advanced users only. Like REDIRECT but only generates the REDIRECT iptables rule and not the companion ACCEPT rule. Requires Shorewall 4.5.14 or later. REJECT disallow the request and return an icmp-unreachable or an RST packet. REJECT! like REJECT but exempts the rule from being suppressed by OPTIMIZE=1 in shorewall6.conf(5). The target may optionally be followed by ":" and a syslog log level (e.g, REJECT:info or Web(ACCEPT):debug). This causes the packet to be logged at the specified level. Note that if the ACTION involves destination network address translation (DNAT, REDIRECT, etc.) then the packet is logged before the destination address is rewritten. If the ACTION names an action declared in shorewall-actions(5) or in /usr/share/shorewall/actions.std then: If the log level is followed by "!' then all rules in the action are logged at the log level. If the log level is not followed by "!" then only those rules in the action that do not specify logging are logged at the specified level. The special log level none! suppresses logging by the action. You may also specify ULOG or NFLOG (must be in upper case) as a log level.This will log to the ULOG or NFLOG target for routing to a separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html). Actions specifying logging may be followed by a log tag (a string of alphanumeric characters) which is appended to the string generated by the LOGPREFIX (in shorewall.conf(5)). Example: ACCEPT:info:ftp would include 'ftp ' at the end of the log prefix generated by the LOGPREFIX setting. SOURCE - {zone|zone-list[+]|{all|any}[+][-]}[:interface][:{address-or-range[,address-or-range]...[exclusion]|exclusion|+ipset|^countrycode-list} Source hosts to which the rule applies. May be a zone declared in /etc/shorewall6/zones, $FW to indicate the firewall itself, all, all+, all-, all+- or none. Beginning with Shorewall 4.4.13, you may use a zone-list which consists of a comma-separated list of zones declared in shorewall-zones (5). This zone-list may be optionally followed by "+" to indicate that the rule is to apply to intra-zone traffic as well as inter-zone traffic. When none is used either in the SOURCE or DEST column, the rule is ignored. all means "All Zones", including the firewall itself. all- means "All Zones, except the firewall itself". When all[-] is used either in the SOURCE or DEST column intra-zone traffic is not affected. When all+[-] is "used, intra-zone traffic is affected. Beginning with Shorewall 4.4.13, exclusion is supported -- see see shorewall6-exclusion(5). Except when all[+][-] or any[+][-] is specified, clients may be further restricted to a list of networks and/or hosts by appending ":" and a comma-separated list of network and/or host addresses. Hosts may be specified by IP or MAC address; mac addresses must begin with "~" and must use "-" as a separator. any is equivalent to all when there are no nested zones. When there are nested zones, any only refers to top-level zones (those with no parent zones). Note that any excludes all vserver zones, since those zones are nested within the firewall zone. Hosts may also be specified as an IP address range using the syntax lowaddress-highaddress. This requires that your kernel and ip6tables contain iprange match support. If your kernel and ip6tables have ipset match support then you may give the name of an ipset prefaced by "+". The ipset name may be optionally followed by a number from 1 to 6 enclosed in square brackets ([]) to indicate the number of levels of source bindings to be matched. Beginning with Shorewall6 4.4.17, the primary IP address of a firewall interface can be specified by an ampersand ('&') followed by the logical name of the interface as found in the INTERFACE column of shorewall6-interfaces (5). Beginning with Shorewall 4.5.4, A countrycode-list may be specified. A countrycode-list is a comma-separated list of up to 15 two-character ISO-3661 country codes enclosed in square brackets ('[...]') and preceded by a caret ('^'). When a single country code is given, the square brackets may be omitted. A list of country codes supported by Shorewall may be found at http://www.shorewall.net/ISO-3661.html. Specifying a countrycode-list requires GeoIP Match support in your ip6tables and Kernel. When an interface is not specified, you may omit the angled brackets ('<' and '>') around the address(es) or you may supply them to improve readability. You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall6-exclusion(5)). Examples: dmz:2002:ce7c::92b4:1::2 Host 2002:ce7c:92b4:1::2 in the DMZ net:2001:4d48:ad51:24::/64 Subnet 2001:4d48:ad51:24::/64 on the Internet loc:<2002:cec792b4:1::2,2002:cec792b4:1::44> Hosts 2002:cec792b4:1::2 and 2002:cec792b4:1::44 in the local zone. loc:~00-A0-C9-15-39-78 Host in the local zone with MAC address 00:A0:C9:15:39:78. net:2001:4d48:ad51:24::/64!2001:4d48:ad51:24:6:/80!2001:4d48:ad51:24:6:/80 Subnet 2001:4d48:ad51:24::/64 on the Internet except for 2001:4d48:ad51:24:6:/80. $FW:&eth0 The primary IP address of eth0 in the firewall zone (Shorewall6 4.4.17 and later). Alternatively, clients may be specified by interface by appending ":" to the zone name followed by the interface name. For example, loc:eth1 specifies a client that communicates with the firewall system through eth1. This may be optionally followed by another colon (":") and an IP/MAC/subnet address as described above (e.g., loc:eth1:<2002:ce7c::92b4:1::2>). Examples: loc:eth1:<2002:cec792b4:1::2,2002:cec792b4:1::44> Hosts 2002:cec792b4:1::2 and 2002:cec792b4:1::44 in the Local zone, with both originating from eth1 DEST - {zone|zone-list[+]|all[+][-]}[:interface][:{address-or-range[,address-or-range]...[exclusion]|exclusion|+ipset|^countrycode-list}[port[:random]] Location of Server. May be a zone declared in shorewall6-zones(5), $FW to indicate the firewall itself, all. all+ or none. Beginning with Shorewall 4.4.13, you may use a zone-list which consists of a comma-separated list of zones declared in shorewall-zones (5). Ths zone-list may be optionally followed by "+" to indicate that the rule is to apply to intra-zone traffic as well as inter-zone traffic. Beginning with Shorewall-4.4.13, exclusion is supported -- see see shorewall6-exclusion(5). Beginning with Shorewall6 4.4.17, the primary IP address of a firewall interface can be specified by an ampersand ('&') followed by the logical name of the interface as found in the INTERFACE column of shorewall6-interfaces (5). Beginning with Shorewall 4.5.4, A countrycode-list may be specified. A countrycode-list is a comma-separated list of up to 15 two-character ISO-3661 country codes enclosed in square brackets ('[...]') and preceded by a caret ('^'). When a single country code is given, the square brackets may be omitted. A list of country codes supported by Shorewall may be found at http://www.shorewall.net/ISO-3661.html. Specifying a countrycode-list requires GeoIP Match support in your ip6tables and Kernel. When none is used either in the SOURCE or DEST column, the rule is ignored. When all is used either in the SOURCE or DEST column intra-zone traffic is not affected. When all+ is used, intra-zone traffic is affected. If the DEST zone is a bport zone, then either: the SOURCE must be , or the SOURCE zone must be another bport zone associated with the same bridge, or the SOURCE zone must be an ipv4 zone that is associated with only the same bridge. Except when all[+]|[-] is specified, the server may be further restricted to a particular network, host or interface by appending ":" and the network, host or interface. See SOURCE above. You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall6-exclusion(5)). Restriction: MAC addresses are not allowed (this is a Netfilter restriction). If you kernel and ip6tables have ipset match support then you may give the name of an ipset prefaced by "+". The ipset name may be optionally followed by a number from 1 to 6 enclosed in square brackets ([]) to indicate the number of levels of destination bindings to be matched. Only one of the SOURCE and DEST columns may specify an ipset name. The port that the server is listening on may be included and separated from the server's IP address by ":". If omitted, the firewall will not modify the destination port. A destination port may only be included if the ACTION is DNAT or REDIRECT. Example 1: loc:[2001:470:b:227::44]:3128 specifies a local server at IP address 2001:470:b:227::44 and listening on port 3128. Example 2: loc:[]:3128 specifies that the destination port should be changed to 3128 but the IP address should remain the same. The port may be specified as a service name. You may specify a port range in the form lowport-highport to cause connections to be assigned to ports in the range in round-robin fashion. When a port range is specified, lowport and highport must be given as integers; service names are not permitted. Additionally, the port range may be optionally followed by :random which causes assignment to ports in the list to be random. If the ACTION is REDIRECT or REDIRECT-, this column needs only to contain the port number on the firewall that the request should be redirected to. That is equivalent to specifying ::port. PROTO - {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all} Optional protocol - ipp2p* requires ipp2p match support in your kernel and ip6tables. tcp:syn implies tcp plus the SYN flag must be set and the RST,ACK and FIN flags must be reset. Beginning with Shorewall6 4.4.19, this column can contain a comma-separated list of protocol-numbers and/or protocol names (e.g., tcp,udp). DEST PORT(S) (dport) - {-|port-name-number-or-range[,port-name-number-or-range]...} Optional destination Ports. A comma-separated list of Port names (from services(5)), port numbers or port ranges; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). ICMP types may be specified as a numeric type, a numeric type and code separated by a slash (e.g., 3/4), or a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP. Note that prior to Shorewall6 4.4.19, only a single ICMP type may be listed. If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example bit for bit-torrent). If no port is given, ipp2p is assumed. A port range is expressed as lowport:highport. This column is ignored if PROTO = all but must be entered if any of the following columns are supplied. In that case, it is suggested that this field contain a dash (-). If your kernel contains multi-port match support, then only a single Netfilter rule will be generated if in this list and the CLIENT PORT(S) list below: 1. There are 15 or less ports listed. 2. No port ranges are included or your kernel and ip6tables contain extended multi-port match support. SOURCE PORT(S) (sport) - {-|port-name-number-or-range[,port-name-number-or-range]...} Optional source port(s). If omitted, any source port is acceptable. Specified as a comma- separated list of port names, port numbers or port ranges. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel. Unless you really understand IP, you should leave this column empty or place a dash (-) in the column. Most people who try to use this column get it wrong. If you don't want to restrict client ports but need to specify a later column, then place "-" in this column. If your kernel contains multi-port match support, then only a single Netfilter rule will be generated if in this list and the DEST PORT(S) list above: 1. There are 15 or less ports listed. 2. No port ranges are included or your kernel and ip6tables contain extended multi-port match support. ORIGINAL DEST (origdest) - [-] Included for compatibility with Shorewall. Enter '-' in this column if you need to specify one of the later columns. RATE LIMIT (rate) - [-|[{s|d}:[[name]:]]]rate/{sec|min|hour|day}[:burst] You may optionally rate-limit the rule by placing a value in this column: rate is the number of connections per interval (sec or min) and burst is the largest burst permitted. If no burst is given, a value of 5 is assumed. There may be no no white-space embedded in the specification. Example: 10/sec:20 When or is specified, the rate applies per source IP address or per destination IP address respectively. The name may be chosen by the user and specifies a hash table to be used to count matching connections. If not given, the name shorewallN (where N is a unique integer) is assumed. Where more than one POLICY specifies the same name, the connections counts for the rules are aggregated and the individual rates apply to the aggregated count. USER/GROUP (user) - [!][user-name-or-number-or-range][:group-name-or-number-or-range] This optional column may only be non-empty if the SOURCE is the firewall itself. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given). Beginning with Shorewall 4.5.8, multiple user or group names/ids separated by commas may be specified. Examples: joe program must be run by joe :kids program must be run by a member of the 'kids' group !:kids program must not be run by a member of the 'kids' group 2001-2099 UIDs 2001 through 2099 (Shorewall 4.5.6 and later) MARK - [!]value[/mask][:C] Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. CONNLIMIT - [!]limit[:mask] May be used to limit the number of simultaneous connections from each individual host to limit connections. Requires connlimit match in your kernel and ip6tables. While the limit is only checked on rules specifying CONNLIMIT, the number of current connections is calculated over all current connections from the SOURCE host. By default, the limit is applied to each host but can be made to apply to networks of hosts by specifying a mask. The mask specifies the width of a VLSM mask to be applied to the source address; the number of current connections is then taken over all hosts in the subnet source-address/mask. When is specified, the rule matches when the number of connection exceeds the limit. TIME - timeelement[&timeelement...] May be used to limit the rule to a particular time period each day, to particular days of the week or month, or to a range defined by dates and times. Requires time match support in your kernel and ip6tables. timeelement may be: timestart=hh:mm[:ss] Defines the starting time of day. timestop=hh:mm[:ss] Defines the ending time of day. 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. HEADERS - [!][any:|exactly:]header-list (Optional - Added in Shorewall 4.4.15) The header-list consists of a comma-separated list of headers from the following list. auth, ah, or 51 Authentication Headers extension header. esp, or 50 Encrypted Security Payload extension header. hop, hop-by-hop or 0 Hop-by-hop options extension header. route, ipv6-route or 41 IPv6 Route extension header. frag, ipv6-frag or 44 IPv6 fragmentation extension header. none, ipv6-nonxt or 59 No next header proto, protocol or 255 Any protocol header. If any: is specified, the rule will match if any of the listed headers are present. If exactly: is specified, the will match packets that exactly include all specified headers. If neither is given, any: is assumed. If ! is entered, the rule will match those packets which would not be matched when ! is omitted. SWITCH - [!]switch-name[={0|1}] Added in Shorewall6 4.4.24 and allows enabling and disabling the rule without requiring shorewall6 restart. Enables the rule if the value stored in /proc/net/nf_condition/switch-name is 1. Disables the rule if that file contains 0 (the default). If '!' is supplied, the test is inverted such that the rule is enabled if the file contains 0. Within the switch-name, '@0' and '@{0}' are replaced by the name of the chain to which the rule is a added. The switch-name (after '@...' expansion) must begin with a letter and be composed of letters, decimal digits, underscores or hyphens. Switch names must be 30 characters or less in length. Switches are normally off. To turn a switch on: echo 1 > /proc/net/nf_condition/switch-name To turn it off again: echo 0 > /proc/net/nf_condition/switch-name Switch settings are retained over shorewall6 restart. Beginning with Shorewall 4.5.10, when the switch-name is followed by or , then the switch is initialized to off or on respectively by the start command. Other commands do not affect the switch setting. HELPER - [helper] Added in Shorewall 4.5.7. In the NEW section, causes the named conntrack helper to be associated with this connection; the contents of this column are ignored unless ACTION is ACCEPT*, DNAT* or REDIRECT*. In the RELATED section, will only match if the related connection has the named helper associated with it. The helper may be one of: If the HELPERS option is specified in shorewall.conf(5), then any module specified in this column must be listed in the HELPERS setting. Example Example 1: Accept SMTP requests from the DMZ to the internet #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST ACCEPT dmz net tcp smtp Example 4: You want to accept SSH connections to your firewall only from internet IP addresses 2002:ce7c::92b4:1::2 and 2002:ce7c::92b4:1::22 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST ACCEPT net:<2002:ce7c::92b4:1::2,2002:ce7c::92b4:1::22> \ $FW tcp 22 Example 5: You wish to limit SSH connections from remote systems to 1/min with a burst of three (to allow for limited retry): #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE # PORT(S) PORT(S) DEST LIMIT SSH(ACCEPT) net all - - - - s:1/min:3 Example 6: Forward port 80 to dmz host $BACKUP if switch 'primary_down' is set. #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH # PORT(S) PORT(S) DEST LIMIT GROUP DNAT net dmz:$BACKUP tcp 80 - - - - - - - - primary_down Example 7: Drop all email from IP addresses in the country whose ISO-3661 country code is ZZ. #ACTION SOURCE DEST PROTO DEST # PORT(S) DROP net:^ZZ fw tcp 25 Example 8: You want to generate your own rule involving ip6tables targets and matches not supported by Shorewall. #ACTION SOURCE DEST PROTO DEST # PORT(S) INLINE $FW net ; -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3 The above will generate the following ip6tables-restore input: -A fw2net -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3 Note that SECCTX must be defined as a builtin action in shorewall6-actions(5): #ACTION OPTIONS SECCTX builtin FILES /etc/shorewall6/rules See ALSO http://www.shorewall.net/shorewall_logging.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-blrules(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/manpages/0000755000175000017500000000000012222401136020670 5ustar teastepteastepshorewall-docs-xml-4.5.21/manpages6/manpages/shorewall6-lite-vardir.xml0000644000175000017500000000566612222401136025735 0ustar teastepteastep shorewall6-lite-vardir 5 vardir Shorewall6 Lite file /etc/shorewall6-lite/vardir Description This file does not exist by default. You may create the file if you want to change the directory used by Shorewall6 Lite to store state information, including compiled firewall scripts. By default, the directory used is /var/lib/shorewall6-lite/. The file contains a single variable assignment: directory where directory is the name of a directory. If you add this file, you should copy the files from /var/lib/shorewall6-lite to the new directory before performing a shorewall6-lite restart. Beginning with Shorewall 4.5.2, use of this file is deprecated in favor of specifying VARDIR in the shorewallrc file used during installation of Shorewall Core. While the name of the variable remains VARDIR, the meaning is slightly different. When set in shorewallrc, Shorewall6 Lite will create a directory under the specified path name to hold state information. Example:
VARDIR=/opt/var/lib/ The state directory for Shorewall Lite will be /opt/var/lib/shorewall6-lite.
When VARDIR is set in /etc/shorewall6-lite/vardir, Shorewall Lite will save its state in the directory specified.
Example VARDIR=/root/shorewall6 FILES /etc/shorewall6-lite/vardir See ALSO shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-route_rules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/manpages/shorewall6-lite.xml0000644000175000017500000011460612222401136024443 0ustar teastepteastep shorewall6-lite 8 shorewall6-lite Administration tool for Shoreline 6 Firewall Lite (Shorewall6 Lite) shorewall6-lite | -options interface[:host-list] zone shorewall6-lite | -options address shorewall6-lite | -options shorewall6-lite | -options interface[:host-list] zone shorewall6-lite | -options { interface | provider } shorewall6-lite | -options address shorewall6-lite | -options shorewall6-lite | -options { interface | provider } shorewall6-lite | -options filename shorewall6-lite | -options shorewall6-lite | -options shorewall6-lite | -options address mask address/vlsm shorewall6-lite | -options address1address2 shorewall6-lite | -options iptables match expression shorewall6-lite | -options address shorewall6-lite | -options refresh-interval shorewall6-lite | -options address shorewall6-lite | -options iptables match expression shorewall6-lite | -options address shorewall6-lite | -options shorewall6-lite | -options directory shorewall6-lite | -options filename shorewall6-lite | -options filename shorewall6-lite | -options {|||} chain shorewall6-lite | -options shorewall6-lite | -options shorewall6-lite | -options event shorewall6-lite | -options shorewall6-lite | -options shorewall6-lite | -options shorewall6-lite | -options shorewall6-lite | -options shorewall6-lite | -options shorewall6-lite | -options Description The shorewall6-lite utility is used to control the Shoreline Firewall Lite (Shorewall Lite). Options The and options are used for debugging. See http://www.shorewall.net/starting_and_stopping_shorewall.htm#Trace. The nolock prevents the command from attempting to acquire the shorewall6-lite lockfile. It is useful if you need to include shorewall commands in /etc/shorewall/started. The options control the amount of output that the command produces. They consist of a sequence of the letters v and q. If the options are omitted, the amount of output is determined by the setting of the VERBOSITY parameter in shorewall6.conf(5). Each v adds one to the effective verbosity and each q subtracts one from the effective VERBOSITY. Alternately, v may be followed immediately with one of -1,0,1,2 to specify a specify VERBOSITY. There may be no white-space between v and the VERBOSITY. The options may also include the letter which causes all progress messages to be timestamped. Commands The available commands are listed below. add Adds a list of hosts or subnets to a dynamic zone usually used with VPN's. The interface argument names an interface defined in the shorewall-interfaces(5) file. A host-list is comma-separated list whose elements are host or network addresses. The add command is not very robust. If there are errors in the host-list, you may see a large number of error messages yet a subsequent shorewall6-lite show zones command will indicate that all hosts were added. If this happens, replace add by delete and run the same command again. Then enter the correct command. allow Re-enables receipt of packets from hosts previously blacklisted by a drop, logdrop, reject, or logreject command. clear Clear will remove all rules and chains installed by shorewall6-lite. The firewall is then wide open and unprotected. Existing connections are untouched. Clear is often used to see if the firewall is causing connection problems. If is given, the command will be processed by the compiled script that executed the last successful start, restart or refresh command if that script exists. delete The delete command reverses the effect of an earlier add command. The interface argument names an interface defined in the shorewall-interfaces(5) file. A host-list is comma-separated list whose elements are a host or network address. disable Added in Shorewall 4.4.26. Disables the optional provider associated with the specified interface or provider. Where more than one provider share a single network interface, a provider name must be given. drop Causes traffic from the listed addresses to be silently dropped. dump Produces a verbose report about the firewall configuration for the purpose of problem analysis. The -x option causes actual packet and byte counts to be displayed. Without that option, these counts are abbreviated. The -m option causes any MAC addresses included in shorewall6-lite log messages to be displayed. The -l option causes the rule number for each Netfilter rule to be displayed. enable Added in Shorewall 4.4.26. Enables the optional provider associated with the specified interface or provider. Where more than one provider share a single network interface, a provider name must be given. forget Deletes /var/lib/shorewall6-lite/filename and /var/lib/shorewall6-lite/save. If no filename is given then the file specified by RESTOREFILE in shorewall6.conf(5) is assumed. help Displays a syntax summary. hits Generates several reports from shorewall6-lite log messages in the current log file. If the option is included, the reports are restricted to log messages generated today. ipcalc Ipcalc displays the network address, broadcast address, network in CIDR notation and netmask corresponding to the input[s]. iprange Iprange decomposes the specified range of IP addresses into the equivalent list of network/host addresses. iptrace This is a low-level debugging command that causes iptables TRACE log records to be created. See iptables(8) for details. The iptables match expression must be one or more matches that may appear in both the raw table OUTPUT and raw table PREROUTING chains. The trace records are written to the kernel's log buffer with facility = kernel and priority = warning, and they are routed from there by your logging daemon (syslogd, rsyslog, syslog-ng, ...) -- shorewall6-lite has no control over where the messages go; consult your logging daemon's documentation. logdrop Causes traffic from the listed addresses to be logged then discarded. Logging occurs at the log level specified by the BLACKLIST_LOGLEVEL setting in shorewall6.conf (5). logwatch Monitors the log file specified by the LOGFILE option in shorewall6.conf(5) and produces an audible alarm when new shorewall6-lite messages are logged. The -m option causes the MAC address of each packet source to be displayed if that information is available. The refresh-interval specifies the time in seconds between screen refreshes. You can enter a negative number by preceding the number with "--" (e.g., shorewall6-lite logwatch -- -30). In this case, when a packet count changes, you will be prompted to hit any key to resume screen refreshes. logreject Causes traffic from the listed addresses to be logged then rejected. Logging occurs at the log level specified by the BLACKLIST_LOGLEVEL setting in shorewall6.conf (5). noiptrace This is a low-level debugging command that cancels a trace started by a preceding iptrace command. The iptables match expression must be one given in the iptrace command being canceled. reset All the packet and byte counters in the firewall are reset. restart Restart is similar to shorewall6-lite start except that it assumes that the firewall is already started. Existing connections are maintained. The option causes shorewall6-lite to avoid updating the routing table(s). The option causes the connection tracking table to be flushed; the conntrack utility must be installed to use this option. restore Restore shorewall6-lite to a state saved using the shorewall6-lite save command. Existing connections are maintained. The filename names a restore file in /var/lib/shorewall6-lite created using shorewall6-lite save; if no filename is given then shorewall6-lite will be restored from the file specified by the RESTOREFILE option in shorewall6.conf(5). save The dynamic blacklist is stored in /var/lib/shorewall6-lite/save. The state of the firewall is stored in /var/lib/shorewall6-lite/filename for use by the shorewall6-lite restore. If filename is not given then the state is saved in the file specified by the RESTOREFILE option in shorewall6.conf(5). show The show command can have a number of different arguments: capabilities Displays your kernel/iptables capabilities. The -f option causes the display to be formatted as a capabilities file for use with compile -e. [ [ ] chain... ] The rules in each chain are displayed using the iptables -L chain -n -v command. If no chain is given, all of the chains in the filter table are displayed. The -x option is passed directly through to iptables and causes actual packet and byte counts to be displayed. Without this option, those counts are abbreviated. The -t option specifies the Netfilter table to display. The default is filter. The -b ('brief') option causes rules which have not been used (i.e. which have zero packet and byte counts) to be omitted from the output. Chains with no rules displayed are also omitted from the output. The -l option causes the rule number for each Netfilter rule to be displayed. If the t option and the keyword are both omitted and any of the listed chains do not exist, a usage message is displayed. classifiers|filters Displays information about the packet classifiers defined on the system as a result of traffic shaping configuration. config Displays distribution-specific defaults. connections Displays the IP connections currently being tracked by the firewall. event event Added in Shorewall 4.5.19. Displays the named event. events Added in Shorewall 4.5.19. Displays all events. ip Displays the system's IPv4 configuration. ipa Added in Shorewall 4.4.17. Displays the per-IP accounting counters (shorewall-accounting (5)). log Displays the last 20 shorewall6-lite messages from the log file specified by the LOGFILE option in shorewall6.conf(5). The -m option causes the MAC address of each packet source to be displayed if that information is available. marks Added in Shorewall 4.4.26. Displays the various fields in packet marks giving the min and max value (in both decimal and hex) and the applicable mask (in hex). nat Displays the Netfilter nat table using the command iptables -t nat -L -n -v.The -x option is passed directly through to iptables and causes actual packet and byte counts to be displayed. Without this option, those counts are abbreviated. policies Added in Shorewall 4.4.4. Displays the applicable policy between each pair of zones. Note that implicit intrazone ACCEPT policies are not displayed for zones associated with a single network where that network doesn't specify . routing Displays the system's IPv4 routing configuration. raw Displays the Netfilter raw table using the command iptables -t raw -L -n -v.The -x option is passed directly through to iptables and causes actual packet and byte counts to be displayed. Without this option, those counts are abbreviated. tc Displays information about queuing disciplines, classes and filters. zones Displays the current composition of the Shorewall zones on the system. start Start Shorewall Lite. Existing connections through shorewall6-lite managed interfaces are untouched. New connections will be allowed only if they are allowed by the firewall rules or policies. The option causes the connection tracking table to be flushed; the conntrack utility must be installed to use this option. stop Stops the firewall. All existing connections, except those listed in shorewall-routestopped(5) or permitted by the ADMINISABSENTMINDED option in shorewall6.conf(5), are taken down. The only new traffic permitted through the firewall is from systems listed in shorewall-routestopped(5) or by ADMINISABSENTMINDED. If is given, the command will be processed by the compiled script that executed the last successful start, restart or refresh command if that script exists. status Produces a short report about the state of the Shorewall-configured firewall. version Displays Shorewall's version. The option is included for compatibility with earlier Shorewall releases and is ignored. EXIT STATUS In general, when a command succeeds, status 0 is returned; when the command fails, a non-zero status is returned. The status command returns exit status as follows: 0 - Firewall is started. 3 - Firewall is stopped or cleared 4 - Unknown state; usually means that the firewall has never been started. See ALSO http://www.shorewall.net/starting_and_stopping_shorewall.htm shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall_interfaces(5), shorewall6-ipsets(5), shorewall6-maclist(5), shorewall6-masq(5), shorewall6-netmap(5), shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-proxyarp(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/manpages/shorewall6-lite.conf.xml0000644000175000017500000001643612222401136025371 0ustar teastepteastep shorewall6-lite.conf 5 shorewall6-lite.conf Shorewall6 Lite global configuration file /etc/shorewall6-lite/shorewall6-lite.conf Description This file sets options that apply to Shorewall6 Lite as a whole. The file consists of Shell comments (lines beginning with '#'), blank lines and assignment statements (variable=value). Each variable's setting is preceded by comments that describe the variable and it's effect. Any option not specified in this file gets its value from the shorewall6.conf file used during compilation of /var/lib/shorewall6-lite/firewall. Those settings may be found in the file /var/lib/shorewall6-lite/firewall.conf. OPTIONS The following options may be set in shorewall6.conf. IP6TABLES=[pathname] This parameter names the ip6tables executable to be used by Shorewall6. If not specified or if specified as a null value, then the ip6tables executable located using the PATH option is used. LOGFILE=[pathname] This parameter tells the /sbin/shorewall6 program where to look for Shorewall6 messages when processing the dump, logwatch, show log, and hits commands. If not assigned or if assigned an empty value, /var/log/messages is assumed. LOGFORMAT=["formattemplate"] The value of this variable generate the --log-prefix setting for Shorewall6 logging rules. It contains a “printf” formatting template which accepts three arguments (the chain name, logging rule number (optional) and the disposition). To use LOGFORMAT with fireparse, set it as: LOGFORMAT="fp=%s:%d a=%s " If the LOGFORMAT value contains the substring “%d” then the logging rule number is calculated and formatted in that position; if that substring is not included then the rule number is not included. If not supplied or supplied as empty (LOGFORMAT="") then “Shorewall6:%s:%s:” is assumed. PATH=pathname[:pathname]... Determines the order in which Shorewall6 searches directories for executable files. RESTOREFILE=[filename] Specifies the simple name of a file in /var/lib/shorewall6 to be used as the default restore script in the shorewall6 save, shorewall6 restore, shorewall6 forget and shorewall6 -f start commands. SHOREWALL_SHELL=[pathname] This option is used to specify the shell program to be used to interpret the compiled script. If not specified or specified as a null value, /bin/sh is assumed. Using a light-weight shell such as ash or dash can significantly improve performance. SUBSYSLOCK=[pathname] This parameter should be set to the name of a file that the firewall should create if it starts successfully and remove when it stops. Creating and removing this file allows Shorewall6 to work with your distribution's initscripts. For RedHat, this should be set to /var/lock/subsys/shorewall6. For Debian, the value is /var/state/shorewall6 and in LEAF it is /var/run/shorewall. VERBOSITY=[number] Shorewall6 has traditionally been very noisy (produced lots of output). You may set the default level of verbosity using the VERBOSITY OPTION. Values are: 0 - Silent. You may make it more verbose using the -v option 1 - Major progress messages displayed 2 - All progress messages displayed (old default behavior) If not specified, then 2 is assumed. FILES /etc/shorewall6-lite/shorewall6.conf See ALSO http://www.shorewall.net/Documentation_Index.html shorewall6-lite(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-ipsec(5), shorewall6-maclist(5), shorewall6-masq(5), shorewall6-nat(5), shorewall6-netmap(5), shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-proxyarp(5), shorewall6-route_rules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-tos.xml0000644000175000017500000001361212222401136022513 0ustar teastepteastep shorewall6-tos 5 tos Shorewall6 Type of Service rules file /etc/shorewall6/tos Description This file defines rules for setting Type Of Service (TOS). Its use is deprecated, beginning in Shorewall 4.5.1, in favor of the TOS target in shorewall6-tcrules (5). The columns in the file are as follows. SOURCE - {all|address]|all:address|$FW} If all, may optionally be followed by ":" and an IP address, a MAC address, a subnet specification or the name of an interface. Example: all:2002:ce7c::92b4:1::2 MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 DEST - {all|address]|all:address} Example: 2002:ce7c::92b4:1::2 PROTOCOL - proto-name-or-number Protocol name or number. SOURCE PORT(S) - {-|port|lowport:highport} Source port or port range. If all ports, use "-". DEST PORT(S) - {-|port|lowport:highport} Destination port or port range. If all ports, use "-" TOS - tos Must be one of the following; tos-minimize-delay (16) tos-maximize-throughput (8) tos-maximize-reliability (4) tos-minimize-cost (2) tos-normal-service (0) To specify more than one flag, add their values together and specify the numeric result. MARK - [!]value[/mask][:C] If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. FILES /etc/shorewall6/tos See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-actions.xml0000644000175000017500000001176212222401136023352 0ustar teastepteastep shorewall6-actions 5 actions shorewall6 action declaration file /etc/shorewall6/actions Description This file allows you to define new ACTIONS for use in rules (see shorewall6-rules(5)). You define the ip6tables rules to be performed in an ACTION in /etc/shorewall6/action.action-name. Columns are: NAME The name of the action. ACTION names should begin with an upper-case letter to distinguish them from Shorewall-generated chain names and be composed of letters, digits or numbers. If you intend to log from the action then the name must be no longer than 11 characters in length if you use the standard LOGFORMAT. OPTIONS Added in Shorewall 4.5.10. Available options are: builtin Added in Shorewall 4.5.16. Defines the action as a rule target that is supported by your ip6tables but is not directly supported by Shorewall. The action may be used as the rule target in an INLINE rule in shorewall6-rules(5). inline Causes the action body (defined in action.action-name) to be expanded in-line like a macro rather than in its own chain. You can list Shorewall Standard Actions in this file to specify the option. Some of the Shorewall standard actions cannot be used in-line and will generate a warning and the compiler will ignore if you try to use them that way: Broadcast DropSmurfs Invalid (Prior to Shorewall 4.5.13) NotSyn (Prior to Shorewall 4.5.13) RST (Prior to Shorewall 4.5.13) TCPFlags noinline Causes any later option for the same action to be ignored with a warning. nolog Added in Shorewall 4.5.11. When this option is specified, the compiler does not automatically apply the log level and/or tag from the invocation of the action to all rules inside of the action. Rather, it simply sets the $_loglevel and $_logtag shell variables which can be used within the action body to apply those logging options only to a subset of the rules. FILES /etc/shorewall6/actions See ALSO http://shorewall.net/Actions.html shorewall6(8), shorewall6-accounting(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcrules.xml0000644000175000017500000014463512222401136023401 0ustar teastepteastep shorewall6-tcrules 5 tcrules Shorewall6 Packet Marking rules file /etc/shorewall6/tcrules Description Entries in this file cause packets to be marked as a means of classifying them for traffic control or policy routing. Unlike rules in the shorewall6-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. If you use multiple internet providers with the 'track' option, in /etc/shorewall6/providers be sure to read the restrictions at http://shorewall.net/MultiISP.html. Beginning with Shorewall 4.5.4, the tcrules file supports two different formats: FORMAT 1 (default - deprecated) The older limited-function version of TPROXY is supported. FORMAT 2 The newer version of TPROXY is supported. The format is specified by a line as follows:
[?]FORMAT {1|2}
The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is the preferred form; the form without the '?' is deprecated. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ACTION - action action may assume one of the following values. A mark value which is an integer in the range 1-255. Normally will set the mark value. If preceded by a vertical bar ("|"), the mark value will be logically ORed with the current mark value to produce a new mark value. If preceded by an ampersand ("&"), will be logically ANDed with the current mark value to produce a new mark value. Both "|" and "&" require Extended MARK Target support in your kernel and ip6tables; neither may be used with connection marks (see below). May optionally be followed by :P, :F or :T, :I where :P indicates that marking should occur in the PREROUTING chain, :F indicates that marking should occur in the FORWARD chain, :I indicates that marking should occur in the INPUT chain (added in Shorewall 4.4.13) and :T indicates that marking should occur in the POSTROUTING chain. If neither :P, :F nor :T follow the mark value then the chain is determined as follows: - If the SOURCE is $FW[:address-or-range[,address-or-range]...], then the rule is inserted into the OUTPUT chain. The behavior changed in Shorewall6-perl 4.1. Only high mark values may be assigned in this case. Packet marking rules for traffic shaping of packets originating on the firewall must be coded in the POSTROUTING chain (see below). - Otherwise, the chain is determined by the setting of MARK_IN_FORWARD_CHAIN in shorewall6.conf(5). Please note that :I is included for completeness and affects neither traffic shaping nor policy routing. If your kernel and ip6tables include CONNMARK support then you can also mark the connection rather than the packet. The mark value may be optionally followed by "/" and a mask value (used to determine those bits of the connection mark to actually be set). When a mask is specified, the result of logically ANDing the mark value with the mask must be the same as the mark value. The mark and optional mask are then followed by one of:+ C Mark the connection in the chain determined by the setting of MARK_IN_FORWARD_CHAIN CF Mark the connection in the FORWARD chain CP Mark the connection in the PREROUTING chain. CT Mark the connection in the POSTROUTING chain CI Mark the connection in the INPUT chain. This option is included for completeness and has no applicability to traffic shaping or policy routing. A mark range which is a pair of integers separated by a dash ("-"). Added in Shorewall 4.5.9. May be optionally followed by a slash ("/") and a mask and requires the Statistics Match capability in iptables and kernel. Marks in the specified range are assigned to packets on a round-robin fashion. When a mask is specified, the result of logically ANDing each mark value with the mask must be the same as the mark value. The least significant bit in the mask is used as an increment. For example, if '0x200-0x400/0xff00' is specified, then the assigned mark values are 0x200, 0x300 and 0x400 in equal proportions. If no mask is specified, then ( 2 ** MASK_BITS ) - 1 is assumed (MASK_BITS is set in shorewall6.conf(5)). May optionally be followed by :P, :F,:T or :I where :P indicates that marking should occur in the PREROUTING chain, :F indicates that marking should occur in the FORWARD chain, :I indicates that marking should occur in the INPUT chain (added in Shorewall 4.4.13), and :T indicates that marking should occur in the POSTROUTING chain. If neither :P, :F nor :T follow the mark value then the chain is determined as follows: - If the SOURCE is $FW[:address-or-range[,address-or-range]...], then the rule is inserted into the OUTPUT chain. When HIGH_ROUTE_MARKS=Yes, 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 chain (see below). - Otherwise, the chain is determined by the setting of MARK_IN_FORWARD_CHAIN in shorewall.conf(5). Please note that :I is included for completeness and affects neither traffic shaping nor policy routing. If your kernel and iptables include CONNMARK support then you can also mark the connection rather than the packet. The mark range may be optionally followed by "/" and a mask value (used to determine those bits of the connection mark to actually be set). When a mask is specified, the result of logically ANDing the mark value with each of the masks must be the same as the mark value. The mark range and optional mask may followed by one of: C Mark the connection in the chain determined by the setting of MARK_IN_FORWARD_CHAIN CF Mark the connection in the FORWARD chain CP Mark the connection in the PREROUTING chain. CT Mark the connection in the POSTROUTING chain CI Mark the connection in the INPUT chain. This option is included for completeness and has no applicability to traffic shaping or policy routing. A classification Id (classid) of the form major:minor where major and minor are integers. Corresponds to the 'class' specification in these traffic shaping modules: atm cbq dsmark pfifo_fast htb prio Classification occurs in the POSTROUTING chain except when the SOURCE is $FW[:address] in which case classification occurs in the OUTPUT chain. When using Shorewall6's built-in traffic shaping tool, the major class is the device number (the first device in shorewall6-tcdevices(5) is major class 1, the second device is major class 2, and so on) and the minor class is the class's MARK value in shorewall6-tcclasses(5) preceded by the number 1 (MARK 1 corresponds to minor class 11, MARK 5 corresponds to minor class 15, MARK 22 corresponds to minor class 122, etc.). Beginning with Shorewall 4.4.27, the classid may be optionally followed by ':' and a capital letter designating the chain where classification is to occur. F FORWARD chain. T POSTROUTING chain (default). CHECKSUM Added in Shorewall 4.5.9. Compute and fill in the checksum in a packet that lacks a checksum. This is particularly useful if you need to work around old applications, such as dhcp clients, that do not work well with checksum offloads, but you don't want to disable checksum offload in your device. Requires 'Checksum Target' support in your kernel and ip6tables. [?]COMMENT -- the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries. The comment will appear delimited by "/* ... */" in the output of shorewall6 show mangle To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. CONTINUE Don't process any more marking rules in the table. As in 1) above, may be followed by :P or :F. Currently, CONTINUE may not be used with exclusion (see the SOURCE and DEST columns below); that restriction will be removed when ip6tables/Netfilter provides the necessary support. DIVERT Added in Shorewall 4.5.3. Two DIVERT rule should precede the TPROXY rule and should select DEST PORT tcp 80 and SOURCE PORT tcp 80 respectively (assuming that tcp port 80 is being proxied). DIVERT avoids sending packets to the TPROXY target once a socket connection to Squid3 has been established by TPROXY. DIVERT marks the packet with a unique mark and exempts it from any rules that follow. DSCP(dscp) Added in Shorewall 4.5.1. Sets the Differentiated Services Code Point field in the IP header. The dscp value may be given as an even number (hex or decimal) or as the name of a DSCP class. Valid class names and their associated hex numeric values are: CS0 => 0x00 CS1 => 0x08 CS2 => 0x10 CS3 => 0x18 CS4 => 0x20 CS5 => 0x28 CS6 => 0x30 CS7 => 0x38 BE => 0x00 AF11 => 0x0a AF12 => 0x0c AF13 => 0x0e AF21 => 0x12 AF22 => 0x14 AF23 => 0x16 AF31 => 0x1a AF32 => 0x1c AF33 => 0x1e AF41 => 0x22 AF42 => 0x24 AF43 => 0x26 EF => 0x2e To indicate more than one class, add their hex values together and specify the result. May be optionally followed by ':' and a capital letter designating the chain where classification is to occur. F FORWARD chain. T POSTROUTING chain. HL([-|+]number) Added in Shorewall 4.4.24. Prior to Shorewall 4.5.7.2, may be optionally followed by :F but the resulting rule is always added to the FORWARD chain. Beginning with Shorewall 4.5.7.s, it may be optionally followed by :P, in which case the rule is added to the PREROUTING chain. If + is included, packets matching the rule will have their HL (hop limit) incremented by number. Similarly, if - is included, matching packets have their HL decremented by number. If neither + nor - is given, the HL of matching packets is set to number. The valid range of values for number is 1-255. IMQ(number) Added in Shorewall 4.5.1. Specifies that the packet should be passed to the IMQ identified by number. Requires IMQ Target support in your kernel and ip6tables. RESTORE[/mask] -- restore the packet's mark from the connection's mark using the supplied mask if any. Your kernel and ip6tables must include CONNMARK support. As in 1) above, may be followed by :P or :F SAME (Added in Shorewall 4.3.5) -- Some websites run applications that require multiple connections from a client browser. Where multiple 'balanced' providers are configured, this can lead to problems when some of the connections are routed through one provider and some through another. The SAME target allows you to work around that problem. SAME may be used in the PREROUTING and OUTPUT chains. When used in PREROUTING, it causes matching connections from an individual local system to all use the same provider. For example: #ACTION SOURCE DEST PROTO DEST # PORT(S) SAME:P 192.168.1.0/24 0.0.0.0/0 tcp 80,443 If a host in 192.168.1.0/24 attempts a connection on TCP port 80 or 443 and it has sent a packet on either of those ports in the last five minutes then the new connection will use the same provider as the connection over which that last packet was sent. When used in the OUTPUT chain, it causes all matching connections to an individual remote system to all use the same provider. For example:#ACTION SOURCE DEST PROTO DEST # PORT(S) SAME $FW 0.0.0.0/0 tcp 80,443 If the firewall attempts a connection on TCP port 80 or 443 and it has sent a packet on either of those ports in the last five minutes to the same remote system then the new connection will use the same provider as the connection over which that last packet was sent. SAVE[/mask] -- save the packet's mark to the connection's mark using the supplied mask if any. Your kernel and ip6tables must include CONNMARK support. As in 1) above, may be followed by :P or :F STATE {NEW|RELATED|ESTABLISHED|INVALID} [,...] Added in Shorewall 4.5.9. The rule will only match if the packet's connection is in one of the listed states. TOS(tos[/mask]) Added in Shorewall 4.5.1. Sets the Type of Service field in the IP header. The tos value may be given as an number (hex or decimal) or as the name of a TOS type. Valid type names and their associated hex numeric values are: Minimize-Delay => 0x10, Maximize-Throughput => 0x08, Maximize-Reliability => 0x04, Minimize-Cost => 0x02, Normal-Service => 0x00 To indicate more than one class, add their hex values together and specify the result. When tos is given as a number, it may be optionally followed by '/' and a mask. When no mask is given, the value 0xff is assumed. When tos is given as a type name, the mask 0x3f is assumed. The action performed is to zero out the bits specified by the mask, then set the bits specified by tos. May be optionally followed by ':' and a capital letter designating the chain where classification is to occur. F FORWARD chain. T POSTROUTING chain (default). TPROXY(mark[,[port][,[address]]]) -- FORMAT 1 Transparently redirects a packet without altering the IP header. Requires a local provider to be defined in shorewall6-providers(5). There are three parameters to TPROXY - only the first (mark) is required: mark - the MARK value corresponding to the local provider in shorewall6-providers(5). port - the port on which the proxy server is listening. If omitted, the original destination port. address - a local (to the firewall) IP address on which the proxy server is listening. If omitted, the IP address of the interface on which the request arrives. TPROXY([port][,[address]]]) -- FORMAT 2 Transparently redirects a packet without altering the IP header. Requires a local provider to be defined in shorewall6-providers(5). There are three parameters to TPROXY - only the first (mark) is required: port - the port on which the proxy server is listening. If omitted, the original destination port. address - a local (to the firewall) IP address on which the proxy server is listening. If omitted, the IP address of the interface on which the request arrives. SOURCE - {-|{interface|$FW}|[{interface|$FW}:]<address-or-range[,address-or-range]...}[exclusion]> Source of the packet. A comma-separated list of interface names, IP addresses, MAC addresses and/or subnets for packets being routed through a common path. List elements may also consist of an interface name followed by ":" and an address (e.g., eth1:<2002:ce7c:92b4::/48>). For example, all packets for connections masqueraded to eth0 from other interfaces can be matched in a single rule with several alternative SOURCE criteria. However, a connection whose packets gets to eth0 in a different way, e.g., direct from the firewall itself, needs a different rule. Accordingly, use $FW in its own separate rule for packets originating on the firewall. In such a rule, the ACTION column may NOT specify either :P or :F because marking for firewall-originated packets always occurs in the OUTPUT chain. MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 When an interface is not specified, the angled brackets ('<' and '>') surrounding the address(es) may be omitted. You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall6-exclusion(5)). DEST - {-|{interface|$FW}[{interface|$FW}:]<address-or-range[,address-or-range]...}[exclusion]> Destination of the packet. Comma separated list of IP addresses and/or subnets. If your kernel and ip6tables include iprange match support, IP address ranges are also allowed. List elements may also consist of an interface name followed by ":" and an address (e.g., eth1:<2002:ce7c:92b4::/48>). If the ACTION column specifies a classification of the form major:minor then this column may also contain an interface name. When an interface is not specified, the angled brackets ('<' and '>') surrounding the address(es) may be omitted. Beginning with Shorewall 4.4.13, $FW may be given by itself or qualified by an address list. This causes marking to occur in the INPUT chain. You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall6-exclusion(5)). PROTO - {-|{tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}[,...]} Protocol - ipp2p requires ipp2p match support in your kernel and ip6tables. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. PORT(S) (dport) - [-|port-name-number-or-range[,port-name-number-or-range]...] Optional destination Ports. A comma-separated list of Port names (from services(5)), port numbers or port ranges; if the protocol is ipv6-icmp, this column is interpreted as the destination icmp-type(s). ICMP types may be specified as a numeric type, a numeric type and code separated by a slash (e.g., 3/4), or a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP. If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example bit for bit-torrent). If no PORT is given, ipp2p is assumed. An entry in this field requires that the PROTO column specify tcp (6), udp (17), ipv6-icmp (58), sctp (132) or udplite (136). Use '-' if any of the following field is supplied. SOURCE PORT(S) (sport) - [-|port-name-number-or-range[,port-name-number-or-range]...] Optional source port(s). If omitted, any source port is acceptable. Specified as a comma-separated list of port names, port numbers or port ranges. An entry in this field requires that the PROTO column specify tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of the following fields is supplied. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel. USER - [!][user-name-or-number][:group-name-or-number] This optional column may only be non-empty if the SOURCE is the firewall itself. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given). Examples: joe program must be run by joe :kids program must be run by a member of the 'kids' group !:kids program must not be run by a member of the 'kids' group TEST - [!]value[/mask][:C] Optional. Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. LENGTH - [length|[min]:[max]] Optional - packet payload length. This field, if present allow you to match the length of a packet payload (Layer 4 data ) against a specific value or range of values. You must have iptables length support for this to work. A range is specified in the form min:max where either min or max (but not both) may be omitted. If min is omitted, then 0 is assumed; if max is omitted, than any packet that is min or longer will match. TOS (Optional) - tos Type of service. Either a standard name, or a numeric value to match. Minimize-Delay (16) Maximize-Throughput (8) Maximize-Reliability (4) Minimize-Cost (2) Normal-Service (0) CONNBYTES - [!]min:[max[:{O|R|B}[:{B|P|A}]]] Optional connection Bytes; defines a byte or packet range that the connection must fall within in order for the rule to match. A packet matches if the the packet/byte count is within the range defined by min and max (unless ! is given in which case, a packet matches if the packet/byte count is not within the range). min is an integer which defines the beginning of the byte/packet range. max is an integer which defines the end of the byte/packet range; if omitted, only the beginning of the range is checked. The first letter gives the direction which the range refers to:
O - The original direction of the connection. R - The opposite direction from the original connection. B - The total of both directions.
If omitted, B is assumed. The second letter determines what the range refers to.
B - Bytes P - Packets A - Average packet size.
If omitted, B is assumed.
HELPER - helper Optional. Names a Netfilter protocol helper module such as , , , etc. A packet will match if it was accepted by the named helper module. Example: Mark all FTP data connections with mark 4:#ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST LENGTH TOS CONNBYTES HELPER # PORT(S) 4 ::/0 ::/0 TCP - - - - - - - ftp HEADERS - [!][any:|exactly:]header-list (Optional - Added in Shorewall 4.4.15) The header-list consists of a comma-separated list of headers from the following list. auth, ah, or 51 Authentication Headers extension header. esp, or 50 Encrypted Security Payload extension header. hop, hop-by-hop or 0 Hop-by-hop options extension header. route, ipv6-route or 41 IPv6 Route extension header. frag, ipv6-frag or 44 IPv6 fragmentation extension header. none, ipv6-nonxt or 59 No next header proto, protocol or 255 Any protocol header. If any: is specified, the rule will match if any of the listed headers are present. If exactly: is specified, the will match packets that exactly include all specified headers. If neither is given, any: is assumed. If ! is entered, the rule will match those packets which would not be matched when ! is omitted. PROBABILITY - [probability] Added in Shorewall 4.5.0. When non-empty, requires the Statistics Match capability in your kernel and ip6tables and causes the rule to match randomly but with the given probability. The probability is a number 0 < probability <= 1 and may be expressed at up to 8 decimal points of precision.
Example Example 1: Mark all forwarded ICMP echo traffic with packet mark 1. Mark all forwarded peer to peer traffic with packet mark 4. 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 means unclassified. #ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST # PORT(S) 1 ::/0 ::/0 icmp echo-request 1 ::/0 ::/0 icmp echo-reply RESTORE ::/0 ::/0 all - - - 0 CONTINUE ::/0 ::/0 all - - - !0 4 ::/0 ::/0 ipp2p:all SAVE ::/0 ::/0 all - - - !0 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. FILES /etc/shorewall6/tcrules See ALSO http://shorewall.net/traffic_shaping.htm http://shorewall.net/MultiISP.html http://shorewall.net/PacketMarking.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-ecn(5), shorewall6-exclusion(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-interfaces.xml0000644000175000017500000006071312222401136024035 0ustar teastepteastep shorewall6-interfaces 5 interfaces shorewall6 interfaces file /etc/shorewall6/interfaces Description The interfaces file serves to define the firewall's network interfaces to shorewall6. The order of entries in this file is not significant in determining zone composition. Beginning with Shorewall 4.5.3, the interfaces file supports two different formats: FORMAT 1 (default - deprecated) There is a ANYCAST column which provides compatibility with older versions of Shorewall.. FORMAT 2 The BROADCAST column is omitted. The format is specified by a line as follows:
[?]FORMAT {1|2}
The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is the preferred form; the form without the '?' is deprecated. The columns in the file are as follows. ZONE - zone-name Zone for this interface. Must match the name of a zone declared in /etc/shorewall6/zones. You may not list the firewall zone in this column. If the interface serves multiple zones that will be defined in the shorewall6-hosts(5) file, you should place "-" in this column. If there are multiple interfaces to the same zone, you must list them in separate entries. Example:
#ZONE INTERFACE BROADCAST loc eth1 - loc eth2 -
Beginning with Shorewall 4.5.17, if you specify a zone for the 'lo' interface, then that zone must be defined as type in shorewall6-zones(5).
INTERFACE - interface[:port] Logical name of interface. Each interface may be listed only once in this file. You may NOT specify the name of a "virtual" interface (e.g., eth0:0) here; see http://www.shorewall.net/FAQ.htm#faq18. If the option is not specified, then the logical name is also the name of the actual interface. You may use wildcards here by specifying a prefix followed by the plus sign ("+"). For example, if you want to make an entry that applies to all PPP interfaces, use 'ppp+'; that would match ppp0, ppp1, ppp2, …Please note that the '+' means 'one or more additional characters' so 'ppp' does not match 'ppp+'. Care must be exercised when using wildcards where there is another zone that uses a matching specific interface. See shorewall6-nesting(5) for a discussion of this problem. Shorewall6 allows '+' as an interface name. There is no need to define the loopback interface (lo) in this file. If a port is given, then the interface must have been defined previously with the option. The OPTIONS column must be empty when a port is given. ANYCAST - - Enter '-' in this column. It is here for compatibility between Shorewall6 and Shorewall and is omitted if FORMAT is 2. OPTIONS (Optional) - [option[,option]...] A comma-separated list of options from the following list. The order in which you list the options is not significant but the list should have no embedded white-space. accept_ra[={0|1|2}] Added in Shorewall 4.5.16. Values are: 0 Do not accept Router Advertisements. 1 Accept Route Advertisements if forwarding is disabled. 2 Overrule forwarding behavior. Accept Route Advertisements even if forwarding is enabled. If the option is specified without a value, then the value 1 is assumed. blacklist Check packets arriving on this interface against the shorewall6-blacklist(5) file. Beginning with Shorewall 4.4.13: If a zone is given in the ZONES column, then the behavior is as if blacklist had been specified in the IN_OPTIONS column of shorewall6-zones(5). Otherwise, the option is ignored with a warning:
WARNING: The 'blacklist' option is ignored on multi-zone interfaces
bridge Designates the interface as a bridge. Beginning with Shorewall 4.4.7, setting this option also sets . destonly Added in Shorewall 4.5.17. Causes the compiler to omit rules to handle traffic from this interface. dhcp Specify this option when any of the following are true: the interface gets its IP address via DHCP the interface is used by a DHCP server running on the firewall the interface has a static IP but is on a LAN segment with lots of DHCP clients. the interface is a simple bridge with a DHCP server on one port and DHCP clients on another port. If you use Shorewall-perl for firewall/bridging, then you need to include DHCP-specific rules in shorewall-rules(8). DHCP uses UDP ports 546 and 547. This option allows DHCP datagrams to enter and leave the interface. forward[={0|1}] Sets the /proc/sys/net/ipv6/conf/interface/forwarding option to the specified value. If no value is supplied, then 1 is assumed. ignore[=1] When specified, causes the generated script to ignore up/down events from Shorewall-init for this device. Additionally, the option exempts the interface from hairpin filtering. When '=1' is omitted, the ZONE column must contain '-' and must be the only OPTION. Beginning with Shorewall 4.5.5, may be specified as '' which only causes the generated script to ignore up/down events from Shorewall-init; hairpin filtering is still applied. In this case, the above restrictions on the ZONE and OPTIONS columns are lifted. mss=number Causes forwarded TCP SYN packets entering or leaving on this interface to have their MSS field set to the specified number. nets=(net[,...]) Limit the zone named in the ZONE column to only the listed networks. If you specify this option, be sure to include the link-local network (ff80::/10). nets=dynamic Added in Shorewall 4.4.21. Defines the zone as dynamic. Requires ipset match support in your iptables and kernel. See http://www.shorewall.net/Dynamic.html for further information. optional When is specified for an interface, shorewall6 will be silent when: a /proc/sys/net/ipv6/conf/ entry for the interface cannot be modified. The first global IPv6 address of the interface cannot be obtained. This option may not be specified together with required. physical=name Added in Shorewall 4.4.4. When specified, the interface or port name in the INTERFACE column is a logical name that refers to the name given in this option. It is useful when you want to specify the same wildcard port name on two or more bridges. See http://www.shorewall.net/bridge-Shorewall-perl.html#Multiple. If the interface name is a wildcard name (ends with '+'), then the physical name must also end in '+'. If is not specified, then it's value defaults to the interface name. required Added in Shorewall 4.4.10. When specified, the firewall will fail to start if the interface named in the INTERFACE column is not usable. May not be specified together with optional. routeback[={0|1}] If specified, indicates that shorewall6 should include rules that allow traffic arriving on this interface to be routed back out that same interface. This option is also required when you have used a wildcard in the INTERFACE column if you want to allow traffic between the interfaces that match the wildcard. If you specify this option, then you should also specify (see below) if you are running Shorewall 4.5.7 or later; otherwise, you should specify (see below). Beginning with Shorewall 4.5.18, you may specify this option to explicitly reset (e.g., routeback=0). This can be used to override Shorewall's default setting for bridge devices which is routeback=1. rpfilter Added in Shorewall 4.5.7. This is an anti-spoofing measure that requires the 'RPFilter Match' capability in your iptables and kernel. It provides a more efficient alternative to the option below. sourceroute[={0|1}] If this option is not specified for an interface, then source-routed packets will not be accepted from that interface unless explicitly enabled via sysconf. Only set this option to 1 (enable source routing) if you know what you are doing. This might represent a security risk and is not usually needed. Only those interfaces with the option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given. This option does not work with a wild-card interface name (e.g., eth0.+) in the INTERFACE column. sfilter=(net[,...]) Added in Shorewall 4.4.20. At this writing (spring 2011), Linux does not support reverse path filtering (RFC3704) for IPv6. In its absence, may be used as an anti-spoofing measure. This option should be used on bridges or other interfaces with the option. On these interfaces, should list those local networks that are connected to the firewall through other interfaces. tcpflags Packets arriving on this interface are checked for certain illegal combinations of TCP flags. Packets found to have such a combination of flags are handled according to the setting of TCP_FLAGS_DISPOSITION after having been logged according to the setting of TCP_FLAGS_LOG_LEVEL. proxyndp[={0|1}] Sets /proc/sys/net/ipv6/conf/interface/proxy_ndp. Note: This option does not work with a wild-card interface name (e.g., eth0.+) in the INTERFACE column. Only those interfaces with the option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given. unmanaged Added in Shorewall 4.5.18. Causes all traffic between the firewall and hosts on the interface to be accepted. When this option is given: The ZONE column must contain '-'. Only the following other options are allowed with unmanaged: accept_ra forward ignore optional physical sourceroute proxyndp wait=seconds Added in Shorewall 4.4.10. Causes the generated script to wait up to seconds seconds for the interface to become usable before applying the required or optional options.
Example Example 1: Suppose you have eth0 connected to a DSL modem and eth1 connected to your local network You have a DMZ using eth2. Your entries for this setup would look like: FORMAT 2 #ZONE INTERFACE OPTIONS net eth0 - loc eth1 - dmz eth2 - Example 4 (Shorewall 4.4.9 and later): You have a bridge with no IP address and you want to allow traffic through the bridge. FORMAT 2 #ZONE INTERFACE OPTIONS - br0 routeback FILES /etc/shorewall6/interfaces See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-exclusion.xml0000644000175000017500000000775512222401136023732 0ustar teastepteastep shorewall6-exclusion 5 exclusion Exclude a set of hosts from a definition in a shorewall6 configuration file. address-or-range[,address-or-range] zone-name[,zone-name] Description Exclusion is used when you wish to exclude one or more addresses from a definition. An exclamation point is followed by a comma-separated list of addresses. The addresses may be single host addresses (e.g., fe80::2a0:ccff:fedb:31c4) or they may be network addresses in CIDR format (e.g., fe80::2a0:ccff:fedb:31c4/64). If your kernel and ip6tables include iprange support, you may also specify ranges of ip addresses of the form lowaddress-highaddress No embedded white-space is allowed. Exclusion can appear after a list of addresses and/or address ranges. In that case, the final list of address is formed by taking the first list and then removing the addresses defined in the exclusion. Beginning in Shorewall 4.4.13, the second form of exclusion is allowed after all and any in the SOURCE and DEST columns of /etc/shorewall/rules. It allows you to omit arbitrary zones from the list generated by those key words. If you omit a sub-zone and there is an explicit or explicit CONTINUE policy, a connection to/from that zone can still be matched by the rule generated for a parent zone. For example:
/etc/shorewall6/zones: #ZONE TYPE z1 ip z2:z1 ip ... /etc/shorewall6/policy: #SOURCE DEST POLICY z1 net CONTINUE z2 net REJECT /etc/shorewall6/rules: #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT all!z2 net tcp 22 In this case, SSH connections from z2 to net will be accepted by the generated z1 to net ACCEPT rule.
FILES /etc/shorewall6/hosts /etc/shorewall6/masq /etc/shorewall6/rules /etc/shorewall6/tcrules See ALSO shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-conntrack.xml0000644000175000017500000004031412222401136023667 0ustar teastepteastep shorewall6-conntrack 5 conntrack shorewall6 conntrack file /etc/shorewall6/conntrack Description The original intent of the notrack file was to exempt certain traffic from Netfilter connection tracking. Traffic matching entries in the file were not to be tracked. The role of the file was expanded in Shorewall 4.4.27 to include all rules that can be added in the Netfilter raw table. In 4.5.7, the file's name was changed to conntrack. The file supports two different column layouts: FORMAT 1, FORMAT 2, and FORMAT 3, FORMAT 1 being the default. The three differ as follows: in FORMAT 2 and 3, there is an additional leading ACTION column. in FORMAT 3, the SOURCE column accepts no zone name; rather the ACTION column allows a SUFFIX that determines the chain(s) that the generated rule will be added to. When an entry in the following form is encountered, the format of the following entries are assumed to be of the specified format. [?]FORMAT format where format is either 1,2 or 3. Format 3 was introduced in Shorewall 4.5.10. The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is the preferred form; the form without the '?' is deprecated. Comments may be attached to Netfilter rules generated from entries in this file through the use of COMMENT lines. These lines begin with the word COMMENT; the remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word COMMENT. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ACTION - {NOTRACK|CT:helper:name[(arg=val[,...])|CT:notrack|drop}[:chain-designator] This column is only present when FORMAT >= 2. Values other than NOTRACK require CT Target support in your iptables and kernel. or Disables connection tracking for this packet. Added in Shorewall 4.5.10. Silently discard the packet. :name Attach the helper identified by the name to this connection. This is more flexible than loading the conntrack helper with preset ports. May be followed by an option list of arg=val pairs in parentheses: =event[,...] Only generate the specified conntrack events for this connection. Possible event types are: new, related, destroy, reply, assured, protoinfo, helper, mark (this is connection mark, not packet mark), natseqinfo, and secmark. If more than one event is listed, the event list must be enclosed in parentheses (e.g., ctevents=(new,related)). Only generate a new expectation events for this connection. When FORMAT = 1, this column is not present and the rule is processed as if NOTRACK had been entered in this column. Beginning with Shorewall 4.5.10, when FORMAT = 3, this column can end with a colon followed by a chain-designator. The chain-designator can be one of the following: P The rule is added to the raw table PREROUTING chain. This is the default if no chain-designator is present. O The rule is added to the raw table OUTPUT chain. PO or OP The rule is added to the raw table PREROUTING and OUTPUT chains. SOURCE (formats 1 and 2) ‒ zone[:interface][:address-list] where zone is the name of a zone, interface is an interface to that zone, and address-list is a comma-separated list of addresses (may contain exclusion - see shorewall6-exclusion (5)). Beginning with Shorewall 4.5.7, can be used as the zone name to mean all zones. Beginning with Shorewall 4.5.10, can be used as the zone name to mean all off-firewall zones. SOURCE (format 3) ‒ {-|interface[:address-list]|address-list} Where interface is an interface to that zone, and address-list is a comma-separated list of addresses (may contain exclusion - see shorewall-exclusion (5)). COMMENT is only allowed in format 1; the remainder of the line is treated as a comment that will be associated with the generated rule(s). DEST ‒ {-|interface[:address-list]|address-list} where address-list is a comma-separated list of addresses (may contain exclusion - see shorewall6-exclusion (5)). PROTO ‒ protocol-name-or-number[,...] A protocol name from /etc/protocols or a protocol number. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. DEST PORT(S) (dport) - port-number/service-name-list A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. SOURCE PORT(S) (sport) - port-number/service-name-list A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). USER/GROUP (user) ‒ [user][:group] May only be specified if the SOURCE zone is $FW. Specifies the effective user id and or group id of the process sending the traffic. SWITCH - [!]switch-name[={0|1}] Added in Shorewall6 4.5.10 and allows enabling and disabling the rule without requiring shorewall6 restart. Enables the rule if the value stored in /proc/net/nf_condition/switch-name is 1. Disables the rule if that file contains 0 (the default). If '!' is supplied, the test is inverted such that the rule is enabled if the file contains 0. Within the switch-name, '@0' and '@{0}' are replaced by the name of the chain to which the rule is a added. The switch-name (after '@...' expansion) must begin with a letter and be composed of letters, decimal digits, underscores or hyphens. Switch names must be 30 characters or less in length. Switches are normally off. To turn a switch on: echo 1 > /proc/net/nf_condition/switch-name To turn it off again: echo 0 > /proc/net/nf_condition/switch-name Switch settings are retained over shorewall6 restart. When the switch-name is followed by or , then the switch is initialized to off or on respectively by the start command. Other commands do not affect the switch setting. EXAMPLES Example 1: Use the FTP helper for TCP port 21 connections from the firewall itself. FORMAT 2 #ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP # PORT(S) PORT(S) CT:helper:ftp(expevents=new) fw - tcp 21 Example 2 (Shorewall 4.5.10 or later): Drop traffic to/from all zones to IP address 2001:1.2.3::4 FORMAT 2 #ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP # PORT(S) PORT(S) DROP all-:2001:1.2.3::4 - DROP all 2001:1.2.3::4 orFORMAT 3 #ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP # PORT(S) PORT(S) DROP:P 2001:1.2.3::4 - DROP:PO - 2001:1.2.3::4 FILES /etc/shorewall6/notrack See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-ipsec(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-proxyarp(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-ipsets.xml0000644000175000017500000001076012222401136023216 0ustar teastepteastep shorewall-ipsets 5 ipsets Specifying the name if an ipset in Shorewall6 configuration files +ipsetname +ipsetname[flag,...] +[ipsetname,...] Description Note: In the above syntax descriptions, the square brackets ("[]") are to be taken literally rather than as meta-characters. In most places where a network address may be entered, an ipset may be substituted. Set names must be prefixed by the character "+", must start with a letter and may be composed of alphanumeric characters, "-" and "_". Whether the set is matched against the packet source or destination is determined by which column the set name appears (SOURCE or DEST). For those set types that specify a tuple, two alternative syntaxes are available: [number] - Indicates that 'src' or 'dst' should repeated number times. Example: myset[2]. [flag,...] where flag is or . Example: myset[src,dst]. In a SOURCE column, the following pairs are equivalent: +myset[2] and +myset[src,src] In a DEST column, the following pairs are equivalent: +myset[2] and +myset[dst,dst] Beginning with Shorewall 4.4.14, multiple source or destination matches may be specified by enclosing the set names within +[...]. The set names need not be prefixed with '+'. When such a list of sets is specified, matching packets must match all of the listed sets. For information about set lists and exclusion, see shorewall-exclusion (5). Beginning with Shorewall 4.5.16, you can increment one or more nfacct objects each time a packet matches an ipset. You do that by listing the objects separated by commas within parentheses. Example: +myset[src](myobject) In that example, when the source address of a packet matches the myset ipset, the myobject nfacct counter will be incremented. Examples +myset +myset[src] +myset[2] +[myset1,myset2[dst]] FILES /etc/shorewall6/accounting /etc/shorewall6/blacklist /etc/shorewall6/hosts -- Note: Multiple matches enclosed in +[...] may not be used in this file. /etc/shorewall6/maclist -- Note: Multiple matches enclosed in +[...] may not be used in this file. /etc/shorewall6/rules /etc/shorewall6/secmarks /etc/shorewall6/tcrules See ALSO shorewall6(8), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-masq.xml0000644000175000017500000004714212222401136022654 0ustar teastepteastep shorewall6-masq 5 masq Shorewall6 Masquerade/SNAT definition file /etc/shorewall6/masq Description Use this file to define Source NAT (SNAT). Requires Shorewall 4.5.14 or later. The entries in this file are order-sensitive. The first entry that matches a particular connection will be the one that is used. If you have more than one ISP link, adding entries to this file will not force connections to go out through a particular link. You must use entries in shorewall6-rtrules(5) or PREROUTING entries in shorewall-tcrules(5) to do that. The columns in the file are as follows. INTERFACE:DEST - {[+]interfacelist|[:[dest-address[,dest-address]...[exclusion]]|[?]COMMENT} Outgoing interfacelist. This may be a comma-separated list of interface names. This is usually your internet interface. Each interface must match an entry in shorewall6-interfaces(5). Shorewall allows loose matches to wildcard entries in shorewall6-interfaces(5). For example, ppp0 in this file will match a shorewall6-interfaces(5) entry that defines ppp+. Where more that one internet provider share a single interface, the provider is specified by including the provider name or number in parentheses: eth0(Avvanta) In that case, you will want to specify the interface's address for that provider in the ADDRESS column. The interface may be qualified by adding the character ":" followed by a comma-separated list of destination host or subnet addresses to indicate that you only want to change the source IP address for packets being sent to those particular destinations. Exclusion is allowed (see shorewall6-exclusion(5)) as are ipset names preceded by a plus sign '+'. Comments may be attached to Netfilter rules generated from entries in this file through the use of COMMENT lines. These lines begin with the word COMMENT; the remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word COMMENT. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. SOURCE - {interface|address[,address][exclusion]} Set of hosts that you wish to SNAT; one or more host or network addresses separated by comma. You may use ipset names preceded by a plus sign (+) to specify a set of hosts. ADDRESS (Optional) - [-|NONAT|[address-or-address-range[,address-or-address-range]...][:lowport-highport][:random][:persistent]|detect|random] If you do not specify an address or address range, masquerading will be performed. This requires Masquerade Target support in your kernel and ip6tables. If you specify an address here, SNAT will be used and this will be the source address. You may also specify a range of up to 256 IP addresses if you want the SNAT address to be assigned from that range in a round-robin fashion by connection. The range is specified by first.ip.in.range-last.ip.in.range. You may follow the port range with:random in which case assignment of ports from the list will be random. random may also be specified by itself in this column in which case random local port assignments are made for the outgoing connections. Example: [2001:470:a:227::2]-[2001:470:a:227::10]:1000-1010 You may follow the port range (or :random) with :persistent. This is only useful when an address range is specified and causes a client to be given the same source/destination IP pair. This column may not contain DNS Names. Normally, Netfilter will attempt to retain the source port number. You may cause netfilter to remap the source port by following an address or range (if any) by ":" and a port range with the format lowport-highport. If this is done, you must specify "tcp" or "udp" in the PROTO column. Examples: [2001:470:a:787::2]:5000-6000 If you simply place NONAT in this column, no rewriting of the source IP address or port number will be performed. This is useful if you want particular traffic to be exempt from the entries that follow in the file. PROTO (Optional) - {-|[!]{protocol-name|protocol-number}[,...]} If you wish to restrict this entry to a particular protocol then enter the protocol name (from protocols(5)) or number here. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. PORT(S) (Optional) - [[!]port-name-or-number[,port-name-or-number]...] If the PROTO column specifies TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136) then you may list one or more port numbers (or names from services(5)) or port ranges separated by commas. Port ranges are of the form lowport:highport. IPSEC (Optional) - [option[,option]...] If you specify a value other than "-" in this column, you must be running kernel 2.6 and your kernel and iptables must include policy match support. Comma-separated list of options from the following. Only packets that will be encrypted via an SA that matches these options will have their source address changed. reqid=number where number is specified using setkey(8) using the 'unique:number option for the SPD level. spi=<number> where number is the SPI of the SA used to encrypt/decrypt packets. proto=ah|esp|ipcomp IPSEC Encapsulation Protocol mss=number sets the MSS field in TCP packets mode=transport|tunnel IPSEC mode tunnel-src=address[/mask] only available with mode=tunnel tunnel-dst=address[/mask] only available with mode=tunnel strict Means that packets must match all rules. next Separates rules; can only be used with strict yes When used by itself, causes all traffic that will be encrypted/encapsulated to match the rule. MARK - [!]value[/mask][:C] Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. USER/GROUP (Optional) - [!][user-name-or-number][:group-name-or-number][+program-name] Only locally-generated connections will match if this column is non-empty. When this column is non-empty, the rule matches only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given). Examples: joe program must be run by joe :kids program must be run by a member of the 'kids' group !:kids program must not be run by a member of the 'kids' group +upnpd #program named upnpd The ability to specify a program name was removed from Netfilter in kernel version 2.6.14. SWITCH - [!]switch-name[={0|1}] Added in Shorewall 4.5.1 and allows enabling and disabling the rule without requiring shorewall restart. The rule is enabled if the value stored in /proc/net/nf_condition/switch-name is 1. The rule is disabled if that file contains 0 (the default). If '!' is supplied, the test is inverted such that the rule is enabled if the file contains 0. Within the switch-name, '@0' and '@{0}' are replaced by the name of the chain to which the rule is a added. The switch-name (after '@...' expansion) must begin with a letter and be composed of letters, decimal digits, underscores or hyphens. Switch names must be 30 characters or less in length. Switches are normally off. To turn a switch on: echo 1 > /proc/net/nf_condition/switch-name To turn it off again: echo 0 > /proc/net/nf_condition/switch-name Switch settings are retained over shorewall restart. Beginning with Shorewall 4.5.10, when the switch-name is followed by or , then the switch is initialized to off or on respectively by the start command. Other commands do not affect the switch setting. ORIGINAL DEST (origdest) - [-|address[,address]...[exclusion]|exclusion] (Optional) This column may be included and may contain one or more addresses (host or network) separated by commas. Address ranges are not allowed. When this column is supplied, rules are generated that require that the original destination address matches one of the listed addresses. It is useful for specifying that SNAT should occur only for connections that were acted on by a DNAT when they entered the firewall. Examples Example 1: You have a simple 'masquerading' setup where eth0 connects to a DSL or cable modem and eth1 connects to your local network with subnet 2001:470:b:787::0/64 Your entry in the file will be: #INTERFACE SOURCE ADDRESS eth0 2001:470:b:787::0/64 - FILES /etc/shorewall6/masq shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcinterfaces.xml0000644000175000017500000002043512222401136024361 0ustar teastepteastep shorewall6-tcinterfaces 5 tcinterfaces Shorewall6 file /etc/shorewall6/tcinterfaces Description This file lists the interfaces that are subject to simple traffic shaping. Simple traffic shaping is enabled by setting TC_ENABLED=Simple in shorewall6.conf(5). A note on the bandwidth definition used in this file: don't use a space between the integer value and the unit: 30kbit is valid while 30 kbit is not. you can use one of the following units: kbps Kilobytes per second. mbps Megabytes per second. kbit Kilobits per second. mbit Megabits per second. bps or number Bytes per second. k or kb Kilo bytes. m or mb Megabytes. Only whole integers are allowed. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). INTERFACE The logical name of an interface. If you run both IPv4 and IPv6 Shorewall firewalls, a given interface should only be listed in one of the two configurations. TYPE - [external|internal] Optional. If given specifies whether the interface is external (facing toward the Internet) or internal (facing toward a local network) and enables SFQ flow classification. Simple traffic shaping is only useful on interfaces where queuing occurs. As a consequence, internal interfaces seldom benefit from simple traffic shaping. VPN interfaces are an exception because the encapsulated packets are later transferred over a slower external link. IN-BANDWIDTH (in_bandwidth) - {-|bandwidth[:burst]|~bandwidth[:interval:decay_interval]} The incoming bandwidth of that interface. Please note that you are not able to do traffic shaping on incoming traffic, as the traffic is already received before you could do so. But this allows you to define the maximum traffic allowed for this interface in total, if the rate is exceeded, the 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 to zero in which case Shorewall will not create an ingress qdisc. Must be set to zero if the REDIRECTED INTERFACES column is non-empty. The optional burst option was added in Shorewall 4.4.18. The default burst is 10kb. A larger burst can help make the bandwidth more accurate; often for fast lines, the enforced rate is well below the specified bandwidth. What is described above creates a rate/burst policing filter. Beginning with Shorewall 4.4.25, a rate-estimated policing filter may be configured instead. Rate-estimated filters should be used with Ethernet adapters that have Generic Receive Offload enabled by default. See Shorewall FAQ 97a. 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. OUT-BANDWIDTH (out_bandwidth) - [rate[:[burst][:[latency][:[peek][:[minburst]]]]]] Added in Shorewall 4.4.13. The terms are defined in tc-tbf(8). Shorewall provides defaults as follows: burst - 10kb latency - 200ms The remaining options are defaulted by tc(8). FILES /etc/shorewall6/tcinterfaces. See ALSO http://ace-host.stuart.id.au/russell/files/tc/doc/sch_tbf.txt http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcpri, shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-hosts.xml0000644000175000017500000001753312222401136023054 0ustar teastepteastep shorewall6-hosts 5 hosts shorewall6 file /etc/shorewall6/hosts Description This file is used to define zones in terms of subnets and/or individual IP addresses. Most simple setups don't need to (should not) place anything in this file. The order of entries in this file is not significant in determining zone composition. Rather, the order that the zones are declared in shorewall6-zones(5) determines the order in which the records in this file are interpreted. The only time that you need this file is when you have more than one zone connected through a single interface. If you have an entry for a zone and interface in shorewall6-interfaces(5) then do not include any entries in this file for that same (zone, interface) pair. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ZONE - zone-name The name of a zone declared in shorewall6-zones(5). You may not list the firewall zone in this column. HOST(S) (hosts)- interface:{[{address-or-range[,address-or-range]...|+ipset}[exclusion] The name of an interface defined in the shorewall6-interfaces(5) file followed by a colon (":") and a comma-separated list whose elements are either: The IPv6 address of a host. A network in CIDR format. An IP address range of the form low.address-high.address. Your kernel and ip6tables must have iprange match support. The name of an ipset. The word which makes the zone dynamic in that you can use the shorewall add and shorewall delete commands to change to composition of the zone. This capability was added in Shorewall 4.4.21.
You may also exclude certain hosts through use of an exclusion (see shorewall6-exclusion(5).
OPTIONS - [option[,option]...] An optional comma-separated list of options from the following list. The order in which you list the options is not significant but the list must have no embedded white-space. blacklist Check packets arriving on this port against the shorewall6-blacklist(5) file. ipsec The zone is accessed via a kernel 2.6 ipsec SA. Note that if the zone named in the ZONE column is specified as an IPSEC zone in the shorewall6-zones(5) file then you do NOT need to specify the 'ipsec' option here. mss=mss Added in Shorewall 4.5.2. When present, causes the TCP mss for new connections to/from the hosts given in the HOST(S) column to be clamped at the specified mss. routeback shorewall6 should set up the infrastructure to pass packets from this/these address(es) back to themselves. This is necessary if hosts in this group use the services of a transparent proxy that is a member of the group or if DNAT is used to send requests originating from this group to a server in the group. tcpflags Packets arriving from these hosts are checked for certain illegal combinations of TCP flags. Packets found to have such a combination of flags are handled according to the setting of TCP_FLAGS_DISPOSITION after having been logged according to the setting of TCP_FLAGS_LOG_LEVEL.
FILES /etc/shorewall6/hosts See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-template.xml0000644000175000017500000000312012222401136023512 0ustar teastepteastep shorewall6- 5 file Shorewall6 file /etc/shorewall6/ Description The columns in the file are as follows. COLUMN 1 Example FILES /etc/shorewall6/ See ALSO shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-exclusion(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-nesting(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-nesting.xml0000644000175000017500000001053612222401136023357 0ustar teastepteastep shorewall6-nesting 5 nesting shorewall6 Nested Zones child-zone[:parent-zone[,parent-zone]...] Description In shorewall6-zones(5), a zone may be declared to be a sub-zone of one or more other zones using the above syntax. The child-zone may be neither the firewall zone nor a vserver zone. The firewall zone may not appear as a parent zone, although all vserver zones are handled as sub-zones of the firewall zone. Where zones are nested, the CONTINUE policy in shorewall6-policy(5) allows hosts that are within multiple zones to be managed under the rules of all of these zones. Example /etc/shorewall6/zones: #ZONE TYPE OPTION fw firewall net ipv6 sam:net ipv6 loc ipv6 /etc/shorewall6/interfaces: #ZONE INTERFACE BROADCAST OPTIONS - eth0 detect blacklist loc eth1 detect /etc/shorewall6/hosts: #ZONE HOST(S) OPTIONS net eth0:[::\] sam eth0:[2001:19f0:feee::dead:beef:cafe] /etc/shorewall6/policy: #SOURCE DEST POLICY LOG LEVEL loc net ACCEPT sam all CONTINUE net all DROP info all all REJECT info The second entry above says that when Sam is the client, connection requests should first be processed under rules where the source zone is sam and if there is no match then the connection request should be treated under rules where the source zone is net. It is important that this policy be listed BEFORE the next policy (net to all). You can have this policy generated for you automatically by using the IMPLICIT_CONTINUE option in shorewall6.conf(5). Partial /etc/shorewall6/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) ... ACCEPT sam loc:2001:19f0:feee::3 tcp ssh ACCEPT net loc:2001:19f0:feee::5 tcp www ... Given these two rules, Sam can connect with ssh to 2001:19f0:feee::3. Like all hosts in the net zone, Sam can connect to TCP port 80 on 2001:19f0:feee::5. The order of the rules is not significant. FILES /etc/shorewall6/zones /etc/shorewall6/interfaces /etc/shorewall6/hosts /etc/shorewall6/policy /etc/shorewall6/rules See ALSO shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-routestopped.xml0000644000175000017500000001650012222401136024442 0ustar teastepteastep shorewall6-routestopped 5 routestopped The Shorewall6 file that governs what traffic flows through the firewall while it is in 'stopped' state. /etc/shorewall6/routestopped Description This file is deprecated in favor of the shorewall6-stoppedrules(5) file. This file is used to define the hosts that are accessible when the firewall is stopped or is being stopped. When shorewall6-shell is being used, the file also determines those hosts that are accessible when the firewall is in the process of being [re]started. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). INTERFACE - interface Interface through which host(s) communicate with the firewall HOST(S) - [-|address[,address]...] Optional comma-separated list of IP/subnet addresses. If your kernel and ip6tables include iprange match support, IP address ranges are also allowed. If left empty or supplied as "-", 0.0.0.0/0 is assumed. OPTIONS - [-|option[,option]...] An optional comma-separated list of options. The order of the options is not important but the list can contain no embedded white-space. The currently-supported options are: routeback Set up a rule to ACCEPT traffic from these hosts back to themselves. Beginning with Shorewall 4.4.9, this option is automatically set if routeback is specified in shorewall6-interfaces (5) or if the rules compiler detects that the interface is a bridge. source Allow traffic from these hosts to ANY destination. Without this option or the dest option, only traffic from this host to other listed hosts (and the firewall) is allowed. If source is specified then routeback is redundant. dest Allow traffic to these hosts from ANY source. Without this option or the source option, only traffic from this host to other listed hosts (and the firewall) is allowed. If dest is specified then routeback is redundant. critical Allow traffic between the firewall and these hosts throughout '[re]start', 'stop' and 'clear'. Specifying critical on one or more entries will cause your firewall to be "totally open" for a brief window during each of those operations. Examples of where you might want to use this are: 'Ping' nodes with heartbeat. LDAP server(s) if you use LDAP Authentication NFS Server if you have an NFS-mounted root filesystem. The source and dest options work best when used in conjunction with ADMINISABSENTMINDED=Yes in shorewall6.conf(5). Example Example 1: #INTERFACE HOST(S) OPTIONS eth2 2002:ce7c:92b4::/64 eth0 2002:ce7c:92b4:1::/64 br0 - routeback eth3 - source FILES /etc/shorewall6/routestopped See ALSO http://shorewall.net/starting_and_stopping_shorewall.htm http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-vardir.xml0000644000175000017500000000404012222401136023170 0ustar teastepteastep shorewall6-vardir 5 vardir Shorewall6 file /etc/shorewall6/vardir Description This file does not exist by default. You may create the file if you want to change the directory used by Shorewall6 to store state information, including compiled firewall scripts. By default, the directory used is /var/lib/shorewall6/. The file contains a single variable assignment: directory where directory is the name of a directory. If you add this file, you should copy the files from /var/lib/shorewall6 to the new directory before performing a shorewall6 restart. Example VARDIR=/root/shorewall6 FILES /etc/shorewall6/vardir See ALSO shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcpri.xml0000644000175000017500000001442312222401136023030 0ustar teastepteastep shorewall6-tcpri 5 tcpri Shorewall6 file /etc/shorewall6/tcpri Description This file is used to specify the priority band of traffic for simple traffic shaping (TC_ENABLED=Simple in shorewall6.conf(5)). The priority band of each packet is determined by the last entry that the packet matches. If a packet doesn't match any entry in this file, then its priority will be determined by its TOS field. The default mapping is as follows but can be changed by setting the TC_PRIOMAP option in shorewall6.conf(5). TOS Bits Means Linux Priority BAND ------------------------------------------------------------ 0x0 0 Normal Service 0 Best Effort 2 0x2 1 Minimize Monetary Cost 1 Filler 3 0x4 2 Maximize Reliability 0 Best Effort 2 0x6 3 mmc+mr 0 Best Effort 2 0x8 4 Maximize Throughput 2 Bulk 3 0xa 5 mmc+mt 2 Bulk 3 0xc 6 mr+mt 2 Bulk 3 0xe 7 mmc+mr+mt 2 Bulk 3 0x10 8 Minimize Delay 6 Interactive 1 0x12 9 mmc+md 6 Interactive 1 0x14 10 mr+md 6 Interactive 1 0x16 11 mmc+mr+md 6 Interactive 1 0x18 12 mt+md 4 Int. Bulk 2 0x1a 13 mmc+mt+md 4 Int. Bulk 2 0x1c 14 mr+mt+md 4 Int. Bulk 2 0x1e 15 mmc+mr+mt+md 4 Int. Bulk 2 The columns in the file are as follows. BAND - {1|2|3} Classifies matching traffic as High Priority (1), Medium Priority (2) or Low Priority (3). For those interfaces listed in shorewall6-tcinterfaces(5), Priority 2 traffic will be deferred so long and there is Priority 1 traffic queued and Priority 3 traffic will be deferred so long as there is Priority 1 or Priority 2 traffic to send. PROTO - protocol[,...] Optional. The name or number of an IPv4 protocol. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. PORT(S) - port [,...] Optional. May only be given if the the PROTO is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136). A list of one or more port numbers or service names from /etc/services. Port ranges of the form lowport:highport may also be included. ADDRESS - [address] Optional. The IP or MAC address that the traffic originated from. MAC addresses must be given in Shorewall format. If this column contains an address, then the PROTO, PORT(S) and INTERFACE column must be empty ("-"). INTERFACE - [interface] Optional. The logical name of an interface that traffic arrives from. If given, the PROTO, PORT(S) and ADDRESS columns must be empty ("-"). INTERFACE classification of packets occurs before classification by PROTO/PORT(S)/ADDRESS. So it is highly recommended to place entries that specify INTERFACE at the top of the file so that the rule about last entry matches is preserved. HELPER - [helper] Optional. Names a Netfilter protocol helper module such as ftp, sip, amanda, etc. A packet will match if it was accepted by the named helper module. You can also append "-" and a port number to the helper module name (e.g., ftp-21) to specify the port number that the original connection was made on. FILES /etc/shorewall6/tcpri See ALSO PRIO(8), shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcinterfaces(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-modules.xml0000644000175000017500000000617512222401136023364 0ustar teastepteastep shorewall6-modules 5 modules shorewall6 file /usr/share/shorewall6/modules /usr/share/shorewall6/helpers Description These files specify which kernel modules shorewall6 will load before trying to determine your ip6tables/kernel's capabilities. The modules file is used when LOAD_HELPERS_ONLY=No in shorewall6.conf(8); the helpers file is used when LOAD_HELPERS_ONLY=Yes. Each record in the files has the following format: loadmodule modulename moduleoption The modulename names a kernel module (without suffix). shorewall6 will search for modules based on your MODULESDIR and MODULE_SUFFIX settings in shorewall6.conf(8). The moduleoptions are passed to modprobe (if installed) or to insmod. The /usr/share/shorewall6/modules file contains a large number of modules. Users are encouraged to copy the file to /etc/shorewall6/modules and modify the copy to load only the modules required or use LOAD_HELPERS_ONLY=Yes. If you build monolithic kernels and have not installed module-init-tools, then create an empty /etc/shorewall6/modules file; that will prevent shorewall6 from trying to load modules at all. Example loadmodule ip_conntrack_ftp ports=21,221 FILES /usr/share/shorewall6/modules /usr/share/shorewall6/helpers /etc/shorewall6/modules /etc/shorewall6/helpers See ALSO shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-blrules.xml0000644000175000017500000003054012222401136023355 0ustar teastepteastep shorewall6-blrules 5 blrules shorewall6 Blacklist file /etc/shorewall6/blrules Description This file is used to perform zone-specific blacklisting and whitelisting. Rules in this file are applied depending on the setting of BLACKLISTNEWONLY in shorewall6.conf(5). If BLACKLISTNEWONLY=No, then they are applied regardless of the connection tracking state of the packet. If BLACKLISTNEWONLY=Yes, they are applied to connections in the NEW and INVALID states. The format of rules in this file is the same as the format of rules in shorewall6-rules (5). The difference in the two files lies in the ACTION (first) column. ACTION- {ACCEPT|BLACKLIST|blacklog|CONTINUE|DROP|A_DROP|REJECT|A_REJECT|WHITELIST|LOG|QUEUE|NFQUEUE[(queuenumber)]|[?]COMMENT|action|macro[(target)]}[:{log-level|none}[!][:tag]] Specifies the action to be taken if the packet matches the rule. Must be one of the following. BLACKLIST Added in Shorewall 4.5.3. This is actually a macro that expands as follows: If BLACKLIST_LOGLEVEL is specified in shorewall6.conf(5), then the macro expands to blacklog. Otherwise it expands to the action specified for BLACKLIST_DISPOSITION in shorewall6.conf(5). blacklog May only be used if BLACKLIST_LOGLEVEL is specified in shorewall6.conf (5). Logs, audits (if specified) and applies the BLACKLIST_DISPOSITION specified in shorewall6.conf (5). ACCEPT|CONTINUE|WHITELIST Exempt the packet from the remaining rules in this file. DROP Ignore the packet. A_DROP and A_DROP! Audited versions of DROP. Requires AUDIT_TARGET support in the kernel and ip6tables. REJECT disallow the packet and return an icmp-unreachable or an RST packet. A_REJECT Audited versions of REJECT. Require AUDIT_TARGET support in the kernel and ip6tables. LOG Simply log the packet and continue with the next rule. QUEUE Queue the packet to a user-space application such as ftwall (http://p2pwall.sf.net). The application may reinsert the packet for further processing. NFLOG[(nflog-parameters)] queues matching packets to a back end logging daemon via a netlink socket then continues to the next rule. See http://www.shorewall.net/shorewall_logging.html. NFQUEUE Queues the packet to a user-space application using the nfnetlink_queue mechanism. If a queuenumber is not specified, queue zero (0) is assumed. [?]COMMENT the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries. The comment will appear delimited by "/* ... */" in the output of "shorewall6 show <chain>". To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. action The name of an action declared in shorewall6-actions(5) or in /usr/share/shorewall6/actions.std. macro The name of a macro defined in a file named macro.macro. If the macro accepts an action parameter (Look at the macro source to see if it has PARAM in the TARGET column) then the macro name is followed by the parenthesized target (ACCEPT, DROP, REJECT, ...) to be substituted for the parameter. Example: FTP(ACCEPT). The ACTION may optionally be followed by ":" and a syslog log level (e.g, REJECT:info or Web(ACCEPT):debug). This causes the packet to be logged at the specified level. If the ACTION names an action declared in shorewall6-actions(5) or in /usr/share/shorewall6/actions.std then: If the log level is followed by "!' then all rules in the action are logged at the log level. If the log level is not followed by "!" then only those rules in the action that do not specify logging are logged at the specified level. The special log level none! suppresses logging by the action. You may also specify NFLOG (must be in upper case) as a log level.This will log to the NFLOG target for routing to a separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html). Actions specifying logging may be followed by a log tag (a string of alphanumeric characters) which is appended to the string generated by the LOGPREFIX (in shorewall6.conf(5)). For the remaining columns, see shorewall6-rules (5). Example Example 1: Drop Teredo packets from the net. DROP net:[2001::/32] all Example 2: Don't subject packets from 2001:DB8::/64 to the remaining rules in the file. WHITELIST net:[2001:DB8::/64] all FILES /etc/shorewall6/blrules See ALSO http://shorewall.net/blacklisting_support.htm http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-routes.xml0000644000175000017500000000676512222401136023242 0ustar teastepteastep shorewall6-routes 5 routes Shorewall6 file /etc/shorewall6/routes Description This file was added in Shorewall 4.4.15 and is used to define routes to be added to provider routing tables. The columns in the file are as follows. PROVIDER The name or number of a provider defined in shorewall6-providers (5). Beginning with Shorewall 4.5.14, you may also enter in this column to add routes to the main routing table. DEST Destination host address or network address. GATEWAY (Optional) If specified, gives the IP address of the gateway to the DEST. Beginning with Shorewall 4.5.14, you may specify in this column to create a blackhole route. Beginning with Shorewall 4.5.15, you may specify or in this column to create a prohibit or unreachable route respectively. DEVICE (Optional) Specifies the device route. If neither DEVICE nor GATEWAY is given, then the INTERFACE specified for the PROVIDER in shorewall6-providers (5).This column must be omitted if , or is specified in the GATEWAY column. Files /etc/shorewall6/routes See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6.xml0000644000175000017500000020006612222401136021711 0ustar teastepteastep shorewall6 8 shorewall6 Administration tool for Shoreline Firewall 6 (Shorewall6) shorewall6 | -options interface[:host-list] zone | zone host-list shorewall6 | -options address shorewall6 | -options directory shorewall6 | -options shorewall6 | -options directory pathname shorewall6 | -options interface[:host-list] zone | zone host-list shorewall | -options { interface | provider } shorewall6 | -options address shorewall6 | -options shorewall | -options { interface | provider } shorewall6 | -options directory1 [user@]system[directory2] shorewall6 | -options filename shorewall6 | -options shorewall6 | -options iptables match expression shorewall6 | -options root-user-name directory system shorewall6 | -options address shorewall6 | -options refresh-interval shorewall6 | -options address shorewall6 | -options iptables match expression shorewall6 | -options - directory chain shorewall6 | -options address shorewall6 | -options root-user-name directory system shorewall6 | -options shorewall6 | -options directory shorewall6 | -options filename shorewall6 | -options timeout directory shorewall6 | -options timeout directory shorewall6 | -options filename shorewall6 | -options {||} chain shorewall6 | -options shorewall6 | -options shorewall6 | -options event shorewall6 | -options shorewall6 | -options shorewall6 | -options directory shorewall6 | -options shorewall6 | -options shorewall6 | -options directory timeout shorewall6 | -options directory shorewall6 | -options Description The shorewall6 utility is used to control the Shoreline Firewall 6 (Shorewall6). Options The and options are used for debugging. See http://www.shorewall.net/starting_and_stopping_shorewall.htm#Trace. The nolock prevents the command from attempting to acquire the Shorewall6 lockfile. It is useful if you need to include shorewall6 commands in /etc/shorewall6/started. The options control the amount of output that the command produces. They consist of a sequence of the letters v and q. If the options are omitted, the amount of output is determined by the setting of the VERBOSITY parameter in shorewall6.conf(5). Each v adds one to the effective verbosity and each q subtracts one from the effective VERBOSITY. Alternatively, v may be followed immediately with one of -1,0,1,2 to specify a specify VERBOSITY. There may be no white-space between v and the VERBOSITY. The options may also include the letter which causes all progress messages to be timestamped. Commands The available commands are listed below. add Added in Shorewall 4.4.21. Adds a list of hosts or subnets to a dynamic zone usually used with VPN's. The interface argument names an interface defined in the shorewall6-interfaces(5) file. A host-list is comma-separated list whose elements are host or network addresses. The add command is not very robust. If there are errors in the host-list, you may see a large number of error messages yet a subsequent shorewall show zones command will indicate that all hosts were added. If this happens, replace add by delete and run the same command again. Then enter the correct command. Beginning with Shorewall 4.5.9, the dynamic_shared zone option (shorewall6-zones(5)) allows a single ipset to handle entries for multiple interfaces. When that option is specified for a zone, the add command has the alternative syntax in which the zone name precedes the host-list. allow Re-enables receipt of packets from hosts previously blacklisted by a drop, logdrop, reject, or logreject command. check Compiles the configuration in the specified directory and discards the compiled output script. If no directory is given, then /etc/shorewall6 is assumed. The -e option causes the compiler to look for a file named capabilities. This file is produced using the command shorewall6-lite show -f capabilities > capabilities on a system with Shorewall6 Lite installed. The option causes the compiler to be run under control of the Perl debugger. The option causes the compiler to be profiled via the Perl command-line option. The option was added in Shorewall 4.5.2 and causes the compiler to print the generated ruleset to standard out. The option was added in Shorewall 4.4.20 and causes a Perl stack trace to be included with each compiler-generated error and warning message. clear Clear will remove all rules and chains installed by Shorewall6. The firewall is then wide open and unprotected. Existing connections are untouched. Clear is often used to see if the firewall is causing connection problems. compile Compiles the current configuration into the executable file pathname. If a directory is supplied, Shorewall6 will look in that directory first for configuration files. If the pathname is omitted, the file firewall in the VARDIR (normally /var/lib/shorewall/) is assumed. A pathname of '-' causes the compiler to send the generated script to it's standard output file. Note that '-v-1' is usually specified in this case (e.g., shorewall6 -v-1 compile -- -) to suppress the 'Compiling...' message normally generated by /sbin/shorewall6. When -e is specified, the compilation is being performed on a system other than where the compiled script will run. This option disables certain configuration options that require the script to be compiled where it is to be run. The use of -e requires the presence of a configuration file named capabilities which may be produced using the command shorewall6-lite show -f capabilities > capabilities on a system with Shorewall6 Lite installed. The -c option was added in Shorewall 4.5.17 and causes conditional compilation of a script. The script specified by pathname (or implied if pathname is omitted) is compiled if it doesn't exist or if there is any file in the directory or in a directory on the CONFIG_PATH that has a modification time later than the file to be compiled. When no compilation is needed, a message is issued and an exit status of zero is returned. The option causes the compiler to be run under control of the Perl debugger. The option causes the compiler to be profiled via the Perl command-line option. The option was added in Shorewall 4.4.20 and causes a Perl stack trace to be included with each compiler-generated error and warning message. delete Added in Shorewall 4.4.21. The delete command reverses the effect of an earlier add command. The interface argument names an interface defined in the shorewall6-interfaces(5) file. A host-list is comma-separated list whose elements are a host or network address. Beginning with Shorewall 4.5.9, the dynamic_shared zone option (shorewall6-zones(5)) allows a single ipset to handle entries for multiple interfaces. When that option is specified for a zone, the delete command has the alternative syntax in which the zone name precedes the host-list. disable Added in Shorewall 4.4.26. Disables the optional provider associated with the specified interface or provider. Where more than one provider share a single network interface, a provider name must be given. Beginning with Shorewall 4.5.10, this command may be used with any optional network interface. interface may be either the logical or physical name of the interface. The command removes any routes added from shorewall6-routes(5) and any traffic shaping configuration for the interface. drop Causes traffic from the listed addresses to be silently dropped. dump Produces a verbose report about the firewall configuration for the purpose of problem analysis. The -x option causes actual packet and byte counts to be displayed. Without that option, these counts are abbreviated. The -m option causes any MAC addresses included in Shorewall6 log messages to be displayed. The -l option causes the rule number for each Netfilter rule to be displayed. enable Added in Shorewall 4.4.26. Enables the optional provider associated with the specified interface or provider. Where more than one provider share a single network interface, a provider name must be given. Beginning with Shorewall 4.5.10, this command may be used with any optional network interface. interface may be either the logical or physical name of the interface. The command sets /proc entries for the interface, adds any route specified in shorewall6-routes(5) and installs the interface's traffic shaping configuration, if any. export If directory1 is omitted, the current working directory is assumed. Allows a non-root user to compile a shorewall6 script and stage it on a system (provided that the user has access to the system via ssh). The command is equivalent to: /sbin/shorewall6 compile -e directory1 directory1/firewall &&\ scp directory1/firewall directory1/firewall.conf [user@]system:[directory2] In other words, the configuration in the specified (or defaulted) directory is compiled to a file called firewall in that directory. If compilation succeeds, then firewall and firewall.conf are copied to system using scp. forget Deletes /var/lib/shorewall6/filename and /var/lib/shorewall6/save. If no filename is given then the file specified by RESTOREFILE in shorewall6.conf(5) is assumed. help Displays a syntax summary. iptrace This is a low-level debugging command that causes iptables TRACE log records to be created. See ip6tables(8) for details. The ip6tables match expression must be one or more matches that may appear in both the raw table OUTPUT and raw table PREROUTING chains. The trace records are written to the kernel's log buffer with facility = kernel and priority = warning, and they are routed from there by your logging daemon (syslogd, rsyslog, syslog-ng, ...) -- Shorewall has no control over where the messages go; consult your logging daemon's documentation. load If directory is omitted, the current working directory is assumed. Allows a non-root user to compile a shorewall6 script and install it on a system (provided that the user has root access to the system via ssh). The command is equivalent to: /sbin/shorewall6 compile -e directory directory/firewall &&\ scp directory/firewall directory/firewall.conf root@system:/var/lib/shorewall6-lite/ &&\ ssh root@system '/sbin/shorewall6-lite start' In other words, the configuration in the specified (or defaulted) directory is compiled to a file called firewall in that directory. If compilation succeeds, then firewall is copied to system using scp. If the copy succeeds, Shorewall6 Lite on system is started via ssh. If -s is specified and the start command succeeds, then the remote Shorewall6-lite configuration is saved by executing shorewall6-lite save via ssh. if -c is included, the command shorewall6-lite show capabilities -f > /var/lib/shorewall6-lite/capabilities is executed via ssh then the generated file is copied to directory using scp. This step is performed before the configuration is compiled. If is included, it specifies that the root user on system is named root-user-name rather than "root". The option was added in Shorewall 4.5.3 and causes a Perl stack trace to be included with each compiler-generated error and warning message. logdrop Causes traffic from the listed addresses to be logged then discarded. Logging occurs at the log level specified by the BLACKLIST_LOGLEVEL setting in shorewall6.conf (5). logwatch Monitors the log file specified by the LOGFILE option in shorewall6.conf(5) and produces an audible alarm when new Shorewall6 messages are logged. The -m option causes the MAC address of each packet source to be displayed if that information is available. The refresh-interval specifies the time in seconds between screen refreshes. You can enter a negative number by preceding the number with "--" (e.g., shorewall6 logwatch -- -30). In this case, when a packet count changes, you will be prompted to hit any key to resume screen refreshes. logreject Causes traffic from the listed addresses to be logged then rejected. Logging occurs at the log level specified by the BLACKLIST_LOGLEVEL setting in shorewall6.conf (5). noiptrace This is a low-level debugging command that cancels a trace started by a preceding iptrace command. The iptables match expression must be one given in the iptrace command being canceled. refresh All steps performed by restart are performed by refresh with the exception that refresh only recreates the chains specified in the command while restart recreates the entire Netfilter ruleset.When no chain name is given to the refresh command, the mangle table is refreshed along with the blacklist chain (if any). This allows you to modify /etc/shorewall6/tcrulesand install the changes using refresh. The listed chains are assumed to be in the filter table. You can refresh chains in other tables by prefixing the chain name with the table name followed by ":" (e.g., nat:net_dnat). Chain names which follow are assumed to be in that table until the end of the list or until an entry in the list names another table. Built-in chains such as FORWARD may not be refreshed. The option was added in Shorewall 4.5.3 causes Shorewall to avoid updating the routing table(s). The option was added in Shorewall 4.5.3 causes the compiler to run under the Perl debugger. The option was added in Shorewall 4.5.3 and causes a Perl stack trace to be included with each compiler-generated error and warning message. The - option was added in Shorewall 4.5.3 and causes Shorewall to look in the given directory first for configuration files. Example:shorewall6 refresh net2fw nat:net_dnat #Refresh the 'net2loc' chain in the filter table and the 'net_dnat' chain in the nat table reload If directory is omitted, the current working directory is assumed. Allows a non-root user to compile a shorewall6 script and install it on a system (provided that the user has root access to the system via ssh). The command is equivalent to: /sbin/shorewall6 compile -e directory directory/firewall &&\ scp directory/firewall directory/firewall.conf root@system:/var/lib/shorewall6-lite/ &&\ ssh root@system '/sbin/shorewall6-lite restart' In other words, the configuration in the specified (or defaulted) directory is compiled to a file called firewall in that directory. If compilation succeeds, then firewall is copied to system using scp. If the copy succeeds, Shorewall6 Lite on system is restarted via ssh. If -s is specified and the restart command succeeds, then the remote Shorewall6-lite configuration is saved by executing shorewall6-lite save via ssh. if -c is included, the command shorewall6-lite show capabilities -f > /var/lib/shorewall6-lite/capabilities is executed via ssh then the generated file is copied to directory using scp. This step is performed before the configuration is compiled. If is included, it specifies that the root user on system is named root-user-name rather than "root". The option was added in Shorewall 4.5.3 and causes a Perl stack trace to be included with each compiler-generated error and warning message. reset [chain, ...] Resets the packet and byte counters in the specified chain(s). If no chain is specified, all the packet and byte counters in the firewall are reset. restart Restart is similar to shorewall6 start except that it assumes that the firewall is already started. Existing connections are maintained. If a directory is included in the command, Shorewall6 will look in that directory first for configuration files. The option causes Shorewall6 to avoid updating the routing table(s). The option causes the connection tracking table to be flushed; the conntrack utility must be installed to use this option. The option causes the compiler to run under the Perl debugger. The option suppresses the compilation step and simply reused the compiled script which last started/restarted Shorewall, provided that /etc/shorewall6 and its contents have not been modified since the last start/restart. The option was added in Shorewall 4.4.20 and performs the compilation step unconditionally, overriding the AUTOMAKE setting in shorewall6.conf(5). When both and are present, the result is determined by the option that appears last. The option was added in Shorewall 4.5.3 and causes a Perl stack trace to be included with each compiler-generated error and warning message. restore Restore Shorewall6 to a state saved using the shorewall6 save command. Existing connections are maintained. The filename names a restore file in /var/lib/shorewall6 created using shorewall6 save; if no filename is given then Shorewall6 will be restored from the file specified by the RESTOREFILE option in shorewall6.conf(5). safe-restart Only allowed if Shorewall6 is running. The current configuration is saved in /var/lib/shorewall6/safe-restart (see the save command below) then a shorewall6 restart is done. You will then be prompted asking if you want to accept the new configuration or not. If you answer "n" or if you fail to answer within 60 seconds (such as when your new configuration has disabled communication with your terminal), the configuration is restored from the saved configuration. If a directory is given, then Shorewall6 will look in that directory first when opening configuration files. Beginning with Shorewall 4.5.0, you may specify a different timeout value using the option. The numeric timeout may optionally be followed by an , or suffix (e.g., 5m) to specify seconds, minutes or hours respectively. If the suffix is omitted, seconds is assumed. safe-start Shorewall6 is started normally. You will then be prompted asking if everything went all right. If you answer "n" or if you fail to answer within 60 seconds (such as when your new configuration has disabled communication with your terminal), a shorewall6 clear is performed for you. If a directory is given, then Shorewall6 will look in that directory first when opening configuration files. Beginning with Shorewall 4.5.0, you may specify a different timeout value using the option. The numeric timeout may optionally be followed by an , or suffix (e.g., 5m) to specify seconds, minutes or hours respectively. If the suffix is omitted, seconds is assumed. save The dynamic blacklist is stored in /var/lib/shorewall6/save. The state of the firewall is stored in /var/lib/shorewall6/filename for use by the shorewall6 restore and shorewall6 -f start commands. If filename is not given then the state is saved in the file specified by the RESTOREFILE option in shorewall6.conf(5). show The show command can have a number of different arguments: actions Produces a report about the available actions (built-in, standard and user-defined). capabilities Displays your kernel/ip6tables capabilities. The -f option causes the display to be formatted as a capabilities file for use with compile -e. [ [ ] chain... ] The rules in each chain are displayed using the ip6tables -L chain -n -v command. If no chain is given, all of the chains in the filter table are displayed. The -x option is passed directly through to ip6tables and causes actual packet and byte counts to be displayed. Without this option, those counts are abbreviated. The -t option specifies the Netfilter table to display. The default is filter. The -b ('brief') option causes rules which have not been used (i.e. which have zero packet and byte counts) to be omitted from the output. Chains with no rules displayed are also omitted from the output. The -l option causes the rule number for each Netfilter rule to be displayed. If the -t option and the keyword are both omitted and any of the listed chains do not exist, a usage message is displayed. classifiers|filters Displays information about the packet classifiers defined on the system as a result of traffic shaping configuration. config Displays distribution-specific defaults. connections Displays the IP connections currently being tracked by the firewall. event event Added in Shorewall 4.5.19. Displays the named event. events Added in Shorewall 4.5.19. Displays all events. ip Displays the system's IPv6 configuration. log Displays the last 20 Shorewall6 messages from the log file specified by the LOGFILE option in shorewall6.conf(5). The -m option causes the MAC address of each packet source to be displayed if that information is available. macros Displays information about each macro defined on the firewall system. mangle Displays the Netfilter mangle table using the command ip6tables -t mangle -L -n -v.The -x option is passed directly through to ip6tables and causes actual packet and byte counts to be displayed. Without this option, those counts are abbreviated. marks Added in Shorewall 4.4.26. Displays the various fields in packet marks giving the min and max value (in both decimal and hex) and the applicable mask (in hex). policies Added in Shorewall 4.4.4. Displays the applicable policy between each pair of zones. Note that implicit intrazone ACCEPT policies are not displayed for zones associated with a single network where that network doesn't specify . Routing Displays the system's IPv6 routing configuration. tc Displays information about queuing disciplines, classes and filters. zones Displays the current composition of the Shorewall6 zones on the system. start Start shorewall6. Existing connections through shorewall6 managed interfaces are untouched. New connections will be allowed only if they are allowed by the firewall rules or policies. If a directory is included in the command, Shorewall6 will look in that directory first for configuration files. If -f is specified, the saved configuration specified by the RESTOREFILE option in shorewall6.conf(5) will be restored if that saved configuration exists and has been modified more recently than the files in /etc/shorewall6. When -f is given, a directory may not be specified. Update: In Shorewall6 4.4.20, a new LEGACY_FASTSTART option was added to shorewall6.conf(5). When LEGACY_FASTSTART=No, the modification times of files in /etc/shorewall6 are compared with that of /var/lib/shorewall6/firewall (the compiled script that last started/restarted the firewall). The option causes Shorewall6 to avoid updating the routing table(s). The option was added in Shorewall 4.4.20 and performs the compilation step unconditionally, overriding the AUTOMAKE setting in shorewall6.conf(5). When both and are present, the result is determined by the option that appears last. The option was added in Shorewall 4.5.3 and causes a Perl stack trace to be included with each compiler-generated error and warning message. stop Stops the firewall. All existing connections, except those listed in shorewall6-routestopped(5) or permitted by the ADMINISABSENTMINDED option in shorewall6.conf(5), are taken down. The only new traffic permitted through the firewall is from systems listed in shorewall6-routestopped(5) or by ADMINISABSENTMINDED. status Produces a short report about the state of the Shorewall6-configured firewall. try If Shorewall6 is started then the firewall state is saved to a temporary saved configuration (/var/lib/shorewall6/.try). Next, if Shorewall6 is currently started then a restart command is issued using the specified configuration directory; otherwise, a start command is performed using the specified configuration directory. if an error occurs during the compilation phase of the restart or start, the command terminates without changing the Shorewall6 state. If an error occurs during the restart phase, then a shorewall6 restore is performed using the saved configuration. If an error occurs during the start phase, then Shorewall6 is cleared. If the start/restart succeeds and a timeout is specified then a clear or restore is performed after timeout seconds. Beginning with Shorewall 4.5.0, the numeric timeout may optionally be followed by an , or suffix (e.g., 5m) to specify seconds, minutes or hours respectively. If the suffix is omitted, seconds is assumed. update Added in Shorewall 4.4.21 and causes the compiler to update /etc/shorewall6/shorewall6.conf then validate the configuration. The update will add options not present in the existing file with their default values, and will move deprecated options with non-defaults to a deprecated options section at the bottom of the file. Your existing shorewall6.conf file is renamed shorewall6.conf.bak. The option causes the updated shorewall6.conf file to be annotated with documentation. The option was added in Shorewall 4.4.26 and causes legacy blacklisting rules (shorewall6-blacklist (5) ) to be converted to entries in the blrules file (shorewall6-blrules (5) ). The blacklist keyword is removed from shorewall6-zones (5), shorewall-interfaces (5) and shorewall6-hosts (5). The unmodified files are saved with a .bak suffix. The option was added in Shorewall 4.5.11. When this option is specified, the compiler will walk through the directories in the CONFIG_PATH replacing FORMAT and COMMENT entries to compiler directives (e.g., ?FORMAT and ?COMMENT. When a file is updated, the original is saved in a .bak file in the same directory. For a description of the other options, see the check command above. version Displays Shorewall6's version. If the option is included, the version of Shorewall will also be displayed. EXIT STATUS In general, when a command succeeds, status 0 is returned; when the command fails, a non-zero status is returned. The status command returns exit status as follows: 0 - Firewall is started. 3 - Firewall is stopped or cleared 4 - Unknown state; usually means that the firewall has never been started. See ALSO http://www.shorewall.net/starting_and_stopping_shorewall.htm shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-secmarks.xml0000644000175000017500000003714212222401136023522 0ustar teastepteastep shorewall6-secmarks 5 secmarks Shorewall6 file /etc/shorewall6/secmarks Description Unlike rules in the shorewall6-rules(5) file, evaluation of rules in this file will continue after a match. So the final secmark for each packet will be the one assigned by the LAST rule that matches. The secmarks file is used to associate an SELinux context with packets. It was added in Shorewall6 version 4.4.13. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). SECMARK - {SAVE|RESTORE|context|[?]COMMENT comment} SAVE If an SELinux context is associated with the packet, the context is saved in the connection. Normally, the remaining columns should be left blank. RESTORE If an SELinux context is not currently associated with the packet, then the saved context (if any) is associated with the packet. Normally, the remaining columns should be left blank. context An SELinux context. [?]COMMENT The remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word COMMENT. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. CHAIN:STATE (chain) - {P|I|F|O|T}[:{N|I|U|IU|NI|NU|NIU|NUI:E|ER}] This column determines the CHAIN where the SELinux context is to be applied: P - PREROUTING I - INPUT F - FORWARD O - OUTPUT T - POSTROUTING It may be optionally followed by a colon and an indication of the Netfilter connection state(s) at which the context is to be applied: :N - NEW connection :I - INVALID connection :NI - NEW or INVALID connection :E - ESTABLISHED connection :ER - ESTABLISHED or RELATED connection Beginning with Shorewall 4.5.10, the following additional options are available :U - UNTRACKED connection :IU - INVALID or UNTRACKED connection :NU - NEW or UNTRACKED connection :NIU - NEW, INVALID or UNTRACKED connection. SOURCE - {-interface|[interface:]address-or-range[,address-or-range]...}[exclusion] May be: An interface name - matches traffic entering the firewall on the specified interface. May not be used in classify rules or in rules using the T in the CHAIN column. A comma-separated list of host or network IP addresses or MAC addresses. An interface name followed by a colon (":") followed by a comma-separated list of host or network IP addresses or MAC addresses. MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall6-exclusion(5)). DEST - {-|{interface|[interface:]address-or-range[,address-or-range]...}[exclusion] May be: An interface name. May not be used in the PREROUTING or INPUT chains. The interface name may be optionally followed by a colon (":") and an IP address list. A comma-separated list of host or network IP addresses. The list may include ip address ranges if your kernel and iptables include iprange support. You may exclude certain hosts from the set already defined through use of an exclusion (see shorewall6-exclusion(5)). PROTO - {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all} Protocol - ipp2p requires ipp2p match support in your kernel and iptables. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. PORT(S) (dport) - [-|port-name-number-or-range[,port-name-number-or-range]...] Optional destination Ports. A comma-separated list of Port names (from services(5)), port numbers or port ranges; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). ICMP types may be specified as a numeric type, a numeric type and code separated by a slash (e.g., 3/4), or a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP. If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example bit for bit-torrent). If no PORT is given, ipp2p is assumed. This column is ignored if PROTOCOL = all but must be entered if any of the following field is supplied. In that case, it is suggested that this field contain "-" SOURCE PORT(S) (sport) - [-|port-name-number-or-range[,port-name-number-or-range]...] Optional source port(s). If omitted, any source port is acceptable. Specified as a comma-separated list of port names, port numbers or port ranges. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel. USER - [!][user-name-or-number][:group-name-or-number] This optional column may only be non-empty if the SOURCE is the firewall itself. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given). Examples: joe program must be run by joe :kids program must be run by a member of the 'kids' group !:kids program must not be run by a member of the 'kids' group MARK - [!]value[/mask][:C] Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. EXAMPLE Mark the first incoming packet of a connection on the loopback interface and destined for address ::1 and tcp port 3306 with context system_u:object_r:mysqld_t:s0 and save that context in the conntrack table. On subsequent input packets in the connection, set the context from the conntrack table. /etc/shorewall6/interfaces: #ZONE INTERFACE BROADCAST OPTIONS - lo - ignore /etc/shorewall6/secmarks: #SECMARK CHAIN: SOURCE DEST PROTO DEST SOURCE USER/ MARK # STATE PORT(S) PORT(S) GROUP system_u:object_r:mysqld_packet_t:s0 I:N lo ::1 tcp 3306 SAVE I:N RESTORE I:ER FILES /etc/shorewall6/secmarks See ALSO http://james-morris.livejournal.com/11010.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-blacklist.xml0000644000175000017500000002131512222401136023655 0ustar teastepteastep shorewall6-blacklist 5 blacklist shorewall6 Blacklist file /etc/shorewall6/blacklist Description The blacklist file is used to perform static blacklisting by source address (IP or MAC), or by application. The use of this file is deprecated in favor of shorewall6-blrules(5), and beginning with Shorewall 4.5.7, the blacklist file is no longer installed. Existing blacklist files can be converted to a corresponding blrules file using the shorewall6 update -b command. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ADDRESS/SUBNET - {-|~mac-address|ip-address|address-range|+ipset} Host address, network address, MAC address, IP address range (if your kernel and ip6tables contain iprange match support) or ipset name prefaced by "+" (if your kernel supports ipset match). Exclusion (shorewall6-exclusion(5)) is supported. MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 A dash ("-") in this column means that any source address will match. This is useful if you want to blacklist a particular application using entries in the PROTOCOL and PORTS columns. PROTOCOL (proto) - {-|protocol-number|protocol-name} Optional - if specified, must be a protocol number or a protocol name from protocols(5). PORTS (port) - {-|port-name-or-number[,port-name-or-number]...} May only be specified if the protocol is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136). A comma-separated list of destination port numbers or service names from services(5). OPTIONS - {-|{dst|src|whitelist|audit}[,...]} Optional - added in 4.4.12. If specified, indicates whether traffic from ADDRESS/SUBNET (src) or traffic to ADDRESS/SUBNET (dst) should be blacklisted. The default is src. If the ADDRESS/SUBNET column is empty, then this column has no effect on the generated rule. In Shorewall 4.4.12, the keywords from and to were used in place of src and dst respectively. Blacklisting was still restricted to traffic arriving on an interface that has the 'blacklist' option set. So to block traffic from your local network to an internet host, you had to specify on your internal interface in shorewall6-interfaces (5). Beginning with Shorewall 4.4.13, entries are applied based on the blacklist setting in shorewall6-zones(5): 'blacklist' in the OPTIONS or IN_OPTIONS column. Traffic from this zone is passed against the entries in this file that have the src option (specified or defaulted). 'blacklist' in the OPTIONS or OUT_OPTIONS column. Traffic to this zone is passed against the entries in this file that have the dst option. In Shorewall 4.4.20, the whitelist option was added. When whitelist is specified, packets/connections that match the entry are not matched against the remaining entries in the file. The audit option was also added in 4.4.20 and causes packets matching the entry to be audited. The audit option may not be specified in whitelist entries and require AUDIT_TARGET support in the kernel and ip6tables. When a packet arrives on an interface that has the blacklist option specified in shorewall6-interfaces(5), its source IP address and MAC address is checked against this file and disposed of according to the BLACKLIST_DISPOSITION and BLACKLIST_LOGLEVEL variables in shorewall6.conf(5). If PROTOCOL or PROTOCOL and PORTS are supplied, only packets matching the protocol (and one of the ports if PORTS supplied) are blocked. Example Example 1: To block DNS queries from address fe80::2a0:ccff:fedb:31c4: #ADDRESS/SUBNET PROTOCOL PORT fe80::2a0:ccff:fedb:31c4/ udp 53 Example 2: To block some of the nuisance applications: #ADDRESS/SUBNET PROTOCOL PORT - udp 1024:1033,1434 - tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898 FILES /etc/shorewall6/blacklist See ALSO http://shorewall.net/blacklisting_support.htm http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-maclist.xml0000644000175000017500000001033112222401136023335 0ustar teastepteastep shorewall6-maclist 5 maclist shorewall6 MAC Verification file /etc/shorewall6/maclist Description This file is used to define the MAC addresses and optionally their associated IPv6 addresses to be allowed to use the specified interface. The feature is enabled by using the maclist option in the shorewall6-interfaces(5) or shorewall6-hosts(5) configuration file. The columns in the file are as follows. DISPOSITION - {ACCEPT|DROP|REJECT}[log-level] ACCEPT or DROP (if MACLIST_TABLE=filter in shorewall6.conf(5), then REJECT is also allowed). If specified, the log-level causes packets matching the rule to be logged at that level. INTERFACE - interface Network interface to a host. MAC - address MAC address of the host -- you do not need to use the shorewall6 format for MAC addresses here. If IP ADDRESSES is supplied then MAC can be supplied as a dash (-) IP ADDRESSES (Optional) - [address[,address]...] If specified, both the MAC and IP address must match. This column can contain a comma-separated list of host and/or subnet addresses. If your kernel and ip6tables have iprange match support then IP address ranges are also allowed. Similarly, if your kernel and ip6tables include ipset support than set names (prefixed by "+") are also allowed. FILES /etc/shorewall6/maclist See ALSO http://shorewall.net/MAC_Validation.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcclasses.xml0000644000175000017500000007465112222401136023704 0ustar teastepteastep shorewall6-tcclasses 5 tcclasses Shorewall6 file to define HTB and HFSC classes /etc/shorewall6/tcclasses Description A note on the rate/bandwidth definitions used in this file: don't use a space between the integer value and the unit: 30kbit is valid while 30 kbit is NOT. you can use one of the following units: kpbs Kilobytes per second. mbps Megabytes per second. kbit Kilobits per second. mbit Megabits per second. bps or number Bytes per second. if you want the values to be calculated for you depending on the output bandwidth setting defined for an interface in tcdevices, you can use expressions like the following: full/3 causes the bandwidth to be calculated as 1/3 of the full outgoing speed that is defined. full*9/10 will set this bandwidth to 9/10 of the full bandwidth Note that in a sub-class (a class that has a specified parent class), full refers to the RATE or CEIL of the parent class rather than to the OUT-BANDWIDTH of the device. DO NOT add a unit to the rate if it is calculated ! The columns in the file are as follows. INTERFACE - interface[[:parent]:class] Name of interface. You may specify either the interface number or the interface name. If the classify option is given for the interface in shorewall6-tcdevices(5), then you must also specify an interface class (an integer that must be unique within classes associated with this interface). You may NOT specify wildcards here, e.g. if you have multiple ppp interfaces, you need to put them all in here! Please note that you can only use interface names in here that have a bandwidth defined in the shorewall6-tcdevices(5) file. Normally, all classes defined here are sub-classes of a root class (class number 1) that is implicitly defined from the entry in shorewall6-tcdevices(5). You can establish a class hierarchy by specifying a parent class -- the number of a class that you have previously defined. The sub-class may borrow unused bandwidth from its parent. MARK - {-|value} The mark value which is an integer in the range 1-255. You set mark values in the shorewall6-tcrules(5) file, marking the traffic you want to fit in the classes defined in here. Must be specified as '-' if the classify option is given for the interface in shorewall6-tcdevices(5) and you are running Shorewall 4.5 5 or earlier. You can use the same marks for different interfaces. RATE - {-|rate[:dmax[:umax]]} The minimum bandwidth this class should get, when the traffic load rises. If the sum of the rates in this column exceeds the INTERFACE's OUT-BANDWIDTH, then the OUT-BANDWIDTH limit may not be honored. Similarly, if the sum of the rates of sub-classes of a class exceed the CEIL of the parent class, things don't work well. When using the HFSC queuing discipline, this column specify the real-time (RT) service curve. leaf classes may specify dmax, the maximum delay in milliseconds that the first queued packet for this class should experience. May be expressed as an integer, optionally followed by 'ms' with no intervening white-space (e.g., 10ms). HFSC leaf classes may also specify umax, the largest packet expected in this class. May be expressed as an integer. The unit of measure is bytes and the integer may be optionally followed by 'b' with no intervening white-space (e.g., 800b). umax may only be given if dmax is also given. Beginning with Shorewall 4.5.6, HFSC classes may omit this column (e.g, '-' in the column), provided that an lsrate is specified (see CEIL below). These rates are used to arbitrate between classes of the same priority. CEIL - [lsrate:]rate 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 needed services (e.g. ssh) are not used. You can use the value full in here for setting the maximum bandwidth to the RATE of the parent class, or the OUT-BANDWIDTH of the device if there is no parent class. Beginning with Shorewall 4.5.6, you can also specify an lsrate (link sharing rate). PRIORITY - priority For HTB:
The priority in which classes will be serviced by the packet shaping scheduler and also the priority in which bandwidth in excess of the rate will be given to each class. Higher priority classes will experience less delay since they are serviced first. Priority values are serviced in ascending order (e.g. 0 is higher priority than 1). Classes may be set to the same priority, in which case they will be serviced as equals.
For both HTB and HFSC, the priority is used to calculate the priority of following Shorewall-generated classification filters that refer to the class: Packet MARK tcp-ack and the tos options (see below) The rules for classes with lower numeric priorities will appear before those with higher numeric priorities. Beginning with Shorewall 4.5.8, the PRIORITY may be omitted from an HFSC class if you do not use the MARK column or the tcp-ack or tos options. If you use those features and omit the PRIORITY, then you must specify a priority along with the MARK or option.
OPTIONS (Optional) - [option[,option]...] 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. You must define default for exactly one class per interface. tos=0xvalue[/0xmask][:priority] (mask defaults to 0xff) This lets you define a classifier for the given value/mask combination of the IP packet's TOS/Precedence/DiffSrv octet (aka the TOS byte). Beginning with Shorewall 4.5.8, the value/mask may be followed by a colon (":") and a priority. This priority determines the order in which filter rules are processed during packet classification. If not specified, the value (class priority << 8) | 10) is used. tos-tosname[:priority] Aliases for the following TOS octet value and mask encodings. TOS encodings of the "TOS byte" have been deprecated in favor of diffserve classes, but programs like ssh, rlogin, and ftp still use them. tos-minimize-delay 0x10/0x10 tos-maximize-throughput 0x08/0x08 tos-maximize-reliability 0x04/0x04 tos-minimize-cost 0x02/0x02 tos-normal-service 0x00/0x1e Beginning with Shorewall 4.5.8, the tos-name may be followed by a colon (":") and a priority. This priority determines the order in which filter rules are processed during packet classification. If not specified, the value (class priority << 8) | 10) is used. Each of these options is only valid for ONE class per interface. tcp-ack[:priority] If defined, causes a tc filter to be created that puts all tcp ack packets on that interface that have a 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 because we want only packets WITHOUT payload to match. Beginning with Shorewall 4.5.8, the tcp-ack may be followed by a colon (":") and a priority. This priority determines the order in which filter rules are processed during packet classification. If not specified, the value (class priority << 8) | 20) is used. This option is only valid for ONE class per interface. flow=keys Shorewall attaches an SFQ queuing discipline to each leaf HTB 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 classifier must be used carefully or it can block off all traffic on an interface! The flow option can be specified for an HTB 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 NAT as the key.
pfifo When specified for a leaf class, the pfifo queuing 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, determines the maximum number of packets that may be queued within the class. The number must be > 2 and <= 128. If not specified, the value 127 is assumed. red=(redoption=value, ...) Added in Shorewall 4.5.6. When specified on a leaf class, causes the class to use the RED (Random Early Detection) queuing discipline rather than SFQ. See tc-red (8) for additional information. Allowable redoptions are: min min Average queue size at which marking becomes a possibility. max max At this average queue size, the marking probability is maximal. Must be at least twice min to prevent synchronous retransmits, higher for low min. probability probability Maximum probability for marking, specified as a floating point number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%, respectively). limit limit Hard limit on the real (not average) queue size in bytes. Further packets are dropped. Should be set higher than max+burst. It is advised to set this a few times higher than max. Shorewall requires that limit be at least twice min. burst burst Used for determining how fast the average queue size is influenced by the real queue size. Larger values make the calculation more sluggish, allowing longer bursts of traffic before marking starts. Real life experiments support the following guide‐line: (min+min+max)/(3*avpkt). avpkt avpkt Optional. Specified in bytes. Used with burst to determine the time constant for average queue size calculations. 1000 is a good value and is the Shorewall default. bandwidth bandwidth Optional. This rate is used for calculating the average queue size after some idle time. Should be set to the bandwidth of your interface. Does not mean that RED will shape for you! ecn RED can either 'mark' or 'drop'. Explicit Congestion Notification allows RED to notify remote hosts that their rate exceeds the amount of bandwidth available. Non-ECN capable hosts can only be notified by dropping a packet. If this parameter is specified, packets which indicate that their hosts honor ECN will only be marked and not dropped, unless the queue size hits limit bytes. Needs a tc binary with RED support compiled in. Recommended. fq_codel[=(codeloption=value, ...)] Added in Shorewall 4.5.12. When specified for 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. Allowable codeloptions are: limit hard limit on the real queue size. When this limit is reached, incoming packets are dropped. If the value is lowered, packets are dropped so that the new limit is met. Default is 1000 packets. flows is the number of flows into which the incoming packets are classified. Due to the stochastic nature of hashing, multiple flows may end up being hashed into the same slot. Newer flows have priority over older ones. This parameter can be set only at load time since memory has to be allocated for the hash table. Default value is 1024. target is the acceptable minimum standing/persistent queue delay. This minimum delay is identified by tracking the local minimum queue delay that packets experience. Default and recommended value is 5ms. interval is used to ensure that the measured minimum delay does not become too stale. The minimum delay must be experienced in the last epoch of length interval. It should be set on the order of the worst-case RTT through the bottleneck to give endpoints sufficient time to react. Default value is 100ms. quantum is the number of bytes used as 'deficit' in the fair queuing algorithm. Default is set to 1514 bytes which corresponds to the Ethernet MTU plus the hardware header length of 14 bytes. ecn | noecn can be used to mark packets instead of dropping them. If ecn has been enabled, noecn can be used to turn it off and vice-a-versa. By default, ecn is enabled.
Examples Example 1: Suppose you are using PPP over Ethernet (DSL) and ppp0 is the interface for this. You have 4 classes here, the first you can use for voice over IP traffic, the second interactive traffic (e.g. ssh/telnet but not scp), the third will be for all unclassified traffic, and the forth is for low priority traffic (e.g. peer-to-peer). The voice traffic in the first class will be guaranteed a minimum of 100kbps and always be serviced first (because of the low priority number, giving less delay) and will be granted excess bandwidth (up to 180kbps, the class ceiling) first, before any other traffic. A single VoIP stream, depending upon codecs, after encapsulation, can take up to 80kbps on a PPPoE/DSL link, so we pad a little bit just in case. (TOS byte values 0xb8 and 0x68 are DiffServ classes EF and AFF3-1 respectively and are often used by VOIP devices). Interactive traffic (tos-minimum-delay) and TCP acks (and ICMP echo traffic if you use the example in tcrules) and any packet with a mark of 2 will be guaranteed 1/4 of the link bandwidth, and may extend up to full speed of the link. Unclassified traffic and packets marked as 3 will be guaranteed 1/4th of the link bandwidth, and may extend to the full speed of the link. Packets marked with 4 will be treated as low priority packets. (The tcrules example marks p2p traffic as such.) If the link is congested, they're only guaranteed 1/8th of the speed, and even if the link is empty, can only expand to 80% of link bandwidth just as a precaution in case there are upstream queues we didn't account for. This is the last class to get additional bandwidth and the last to get serviced by the scheduler because of the low priority. #INTERFACE MARK RATE CEIL PRIORITY OPTIONS ppp0 1 100kbit 180kbit 1 tos=0x68/0xfc,tos=0xb8/0xfc ppp0 2 full/4 full 2 tcp-ack,tos-minimize-delay ppp0 3 full/4 full 3 default ppp0 4 full/8 full*8/10 4 FILES /etc/shorewall6/tcclasses See ALSO tc-hfsc(7) tc-red(8) http://shorewall.net/traffic_shaping.htm http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcfilters.xml0000644000175000017500000002451212222401136023706 0ustar teastepteastep shorewall6-tcfilters 5 tcfilters shorewall6 u32 classifier rules file /etc/shorewall6/tcfilters Description Entries in this file cause packets to be classified for traffic shaping. Beginning with Shorewall 4.4.15, the file may contain entries for both IPv4 and IPv6. By default, all rules apply to IPv6 but that can be changed by inserting a line as follows: IPV4 Following entries apply to IPv4. IPV6 Following entries apply to IPv6 ALL Following entries apply to both IPv4 and IPv6. Each entry is processed twice; once for IPv4 and once for IPv6. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). CLASS - interface:class The name or number of an interface defined in shorewall6-tcdevices(5) followed by a class number defined for that interface in shorewall6-tcclasses(5). SOURCE - {-|address} Source of the packet. May be a host or network address. DNS names are not allowed. DEST - {-|address}} Destination of the packet. May be a host or network address. DNS names are not allowed. PROTO - {-|{protocol-number|protocol-name|all}[,...]} Protocol. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. DEST PORT (dport) - [-|port-name-or-number] Optional destination Ports. A Port name (from services(5)) or a port number; if the protocol is icmp, this column is interpreted as the destination icmp-type(s). SOURCE PORT (sport) - [-|port-name-or-number] Optional source port. TOS - [-|tos] Optional - specifies the value of the TOS field. The tos value can be any of the following: hex-number hex-number/hex-number The hex-numbers must be exactly two digits (e.g., 0x04)x. LENGTH - [-|number] Optional. Must be a power of 2 between 32 and 8192 inclusive. Packets with a total length that is strictly less than the specified number will match the rule. PRIORITY - [-|number] Added in Shorewall 4.5.8. Specifies the rule priority. The priority value must be > 0 and <= 65535. When a priority is not given: For Shorewall versions prior to 4.5.8 - all filters have priority 11. For Shorewall 4.5.8 and later - for each device, the compiler maintains a high-water priority with an initial value of 0. When a filter has no priority, the high-water priority is incremented by 1 and assigned to the filter. When a priority greater than the high-water priority is entered in this column, the high-water priority is set to the specified priority. An attempt to assign a priority value greater than 65535 (explicitly or implicitly) raises an error. The default priority values used by other Shorewall-generated filters are as follows: Classify by packet mark - ( class priority << 8 ) | 20. Ingress policing - 10 Simple TC ACK packets - 1 Complex TC ACK packets - ( class priority << 8 ) | 20. Classify by TOS - ( class priority << 8 ) | 15. Class with 'occurs' - 65535 Example Example 1: Place all 'ping' traffic on interface 1 in class 10. Note that ALL cannot be used because IPv4 ICMP and IPv6 ICMP are two different protocols. #CLASS SOURCE DEST PROTO DEST # PORT IPV4 1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-reply IPV6 1:10 ::/0 ::/0 icmp6 echo-request 1:10 ::/0 ::/0 icmp6 echo-reply Example 2: Add two filters with priority 10 (Shorewall 4.5.8 or later). #CLASS SOURCE DEST PROTO DEST PRIORITY # PORT IPV6 1:10 ::/0 ::/0 icmp echo-request 10 1:10 ::/0 ::/0 icmp echo-reply 10 FILES /etc/shorewall6/tcfilters See ALSO http://shorewall.net/traffic_shaping.htm http://shorewall.net/MultiISP.html http://shorewall.net/PacketMarking.html shorewall-docs-xml-4.5.21/manpages6/shorewall6-providers.xml0000644000175000017500000004000012222401136023712 0ustar teastepteastep shorewall6-providers 5 providers Shorewall6 Providers file /etc/shorewall6/providers Description This file is used to define additional routing tables. You will want to define an additional table if: You have connections to more than one ISP or multiple connections to the same ISP You run Squid as a transparent proxy on a host other than the firewall. You have other requirements for policy routing. Each entry in the file defines a single routing table. If you wish to omit a column entry but want to include an entry in the next column, use "-" for the omitted entry. The columns in the file are as follows. NAME - name The provider name. Must be a valid shell variable name. The names 'local', 'main', 'default' and 'unspec' are reserved and may not be used as provider names. NUMBER - number The provider number -- a number between 1 and 15. Each provider must be assigned a unique value. MARK (Optional) - value A FWMARK value used in your shorewall6-tcrules(5) file to direct packets to this provider. If HIGH_ROUTE_MARKS=Yes in shorewall6.conf(5), then the value must be a multiple of 256 between 256 and 65280 or their hexadecimal equivalents (0x0100 and 0xff00 with the low-order byte of the value being zero). Otherwise, the value must be between 1 and 255. Each provider must be assigned a unique mark value. This column may be omitted if you don't use packet marking to direct connections to a particular provider. DUPLICATE - routing-table-name The name of an existing table to duplicate to create this routing table. May be or the name of a previously listed provider. You may select only certain entries from the table to copy by using the COPY column below. INTERFACE - interface The name of the network interface to the provider. Must be listed in shorewall6-interfaces(5). GATEWAY - {-|address|detect} The IP address of the provider's gateway router. You can enter "detect" here and Shorewall6 will attempt to detect the gateway automatically. For PPP devices, you may omit this column. OPTIONS (Optional) - [-|option[,option]...] A comma-separated list selected from the following. The order of the options is not significant but the list may contain no embedded white-space. autosrc Added in Shorewall 4.5.17. Causes a host route to the provider's gateway router to be added to the provider's routing table. This is the default behavior unless overridden by a following noautosrc option. balance Added in Shorewall 4.4.25. Causes a default route to this provider's gateway to be added to the main routing table (USE_DEFAULT_RT=No) or to the balance routing table (USE_DEFAULT_RT=Yes). At most one provider can specify this option. fallback Added in Shorewall 4.4.25. Causes a default route to this provider's gateway to be added to the default routing table.At most one provider can specify this option. track If specified, inbound connections on this interface are to be tracked so that responses may be routed back out this same interface. You want to specify if internet hosts will be connecting to local servers through this provider. Beginning with Shorewall 4.4.3, defaults to the setting of the TRACK_PROVIDERS option in shorewall6.conf (5). If you set TRACK_PROVIDERS=Yes and want to override that setting for an individual provider, then specify (see below). loose Shorewall6 normally adds a routing rule for each IP address on an interface which forces traffic whose source is that IP address to be sent using the routing table for that interface. Setting prevents creation of such rules on this interface. noautosrc Added in Shorewall 4.5.17. Prevents the addition of a host route to the provider's gateway router from being added to the provider's routing table. This option must be used with caution as it can cause start and restart failures. notrack Added in Shorewall 4.4.3. When specified, turns off . optional (deprecated for use with providers that do not share an interface) If the interface named in the INTERFACE column is not up and configured with an IPv4 address then ignore this provider. If not specified, the value of the option for the INTERFACE in shorewall6-interfaces(5) is assumed. Use of that option is preferred to this one, unless an address is provider in the INTERFACE column. src=source-address Specifies the source address to use when routing to this provider and none is known (the local client has bound to the 0 address). May not be specified when an address is given in the INTERFACE column. If this option is not used, Shorewall6 substitutes the primary IP address on the interface named in the INTERFACE column. mtu=number Specifies the MTU when forwarding through this provider. If not given, the MTU of the interface named in the INTERFACE column is assumed. tproxy Added in Shorewall 4.5.4. Used for supporting the TPROXY action in shorewall-tcrules(5). See http://www.shorewall.net/Shorewall_Squid_Usage.html. When specified, the MARK, DUPLICATE and GATEWAY columns should be empty, INTERFACE should be set to 'lo' and should be the only OPTION. Only one provider is allowed. hostroute Added in Shorewall 4.5.21. This is the default behavior that results in a host route to the defined GATEWAY being inserted into the main routing table and into the provider's routing table. hostroute is required for older distributions but nohostroute (below) is appropriate for recent distributions. hostroute may interfere with Zebra's ability to add routes on some distributions such as Debian 7. nohostroute Added in Shorewall 4.5.21. nohostroute inhibits addition of a host route to the defined GATEWAY being inserted into the main routing table and into the provider's routing table. nohostroute is not appropriate for older distributions but is appropriate for recent distributions. nohostroute allows Zebra's to correctly add routes on some distributions such as Debian 7. COPY - [{|interface[,interface]...}] A comma-separated list of other interfaces on your firewall. Wildcards specified using an asterisk ("*") are permitted (e.g., tun* ). Usually used only when DUPLICATE is . Only copy routes through INTERFACE and through interfaces listed here. If you only wish to copy routes through INTERFACE, enter in this column. Beginning with Shorewall 4.5.17, blackhole, unreachable and prohibit routes are no longer copied by default but may be copied by including blackhole,unreachable and prohibit respectively in the COPY list. Examples Example 1: You run squid in your DMZ on IP address 2002:ce7c:92b4:1::2. Your DMZ interface is eth2 #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS Squid 1 1 - eth2 2002:ce7c:92b4:1::2 - Example 2: eth0 connects to ISP 1. The ISP's gateway router has IP address 2001:ce7c:92b4:1::2. eth1 connects to ISP 2. The ISP's gateway router has IP address 2001:d64c:83c9:12::8b. eth2 connects to a local network. #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY ISP1 1 1 main eth0 2001:ce7c:92b4:1::2 track eth2 ISP2 2 2 main eth1 2001:d64c:83c9:12::8b track eth2 FILES /etc/shorewall6/providers See ALSO http://shorewall.net/MultiISP.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-rtrules.xml0000644000175000017500000001416112222401136023406 0ustar teastepteastep shorewall6-rtrules 5 rtrules Shorewall6 Routing Rules file /etc/shorewall6/rtrules Description Entries in this file cause traffic to be routed to one of the providers listed in shorewall6-providers(5). The columns in the file are as follows. SOURCE (Optional) - {-|interface|address|interface:<address>} An ip address (network or host) that matches the source IP address in a packet. May also be specified as an interface name optionally followed by ":" and an address. If the device lo is specified, the packet must originate from the firewall itself. Beginning with Shorewall 4.5.0, you may specify &interface in this column to indicate that the source is the primary IP address of the named interface. DEST (Optional) - {-|address} An ip address (network or host) that matches the destination IP address in a packet. If you choose to omit either SOURCE or DEST, place "-" in that column. Note that you may not omit both SOURCE and DEST. PROVIDER - {provider-name|provider-number|main} The provider to route the traffic through. May be expressed either as the provider name or the provider number. May also be main or 254 for the main routing table. This can be used in combination with VPN tunnels, see example 2 below. PRIORITY - priority The rule's numeric priority which determines the order in which the rules are processed. Rules with equal priority are applied in the order in which they appear in the file. 1000-1999 Before Shorewall6-generated 'MARK' rules 11000-11999 After 'MARK' rules but before Shorewall6-generated rules for ISP interfaces. 26000-26999 After ISP interface rules but before 'default' rule. MARK - {-|mark[/mask]} Optional -- added in Shorewall 4.4.25. For this rule to be applied to a packet, the packet's mark value must match the mark when logically anded with the mask. If a mask is not supplied, Shorewall supplies a suitable provider mask. Examples Example 1: You want all traffic coming in on eth1 to be routed to the ISP1 provider. #SOURCE DEST PROVIDER PRIORITY MASK eth1 - ISP1 1000 FILES /etc/shorewall6/rtrules See ALSO http://shorewall.net/MultiISP.html shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-tunnels.xml0000644000175000017500000002471212222401136023401 0ustar teastepteastep shorewall6-tunnels 5 tunnels Shorewall6 VPN definition file /etc/shorewall6/tunnels Description The tunnels file is used to define rules for encapsulated (usually encrypted) traffic to pass between the Shorewall6 system and a remote gateway. Traffic flowing through the tunnel is handled using the normal zone/policy/rule mechanism. See http://www.shorewall.net/VPNBasics.html for details. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). TYPE - {ipsec[:{noah|ah}]|ipsecnat|gre|l2tp|pptpclient|pptpserver|{openvpn|openvpnclient|openvpnserver}[:{tcp|udp}][:port]|generic:protocol[:port]} Types are as follows: ipsec - IPv6 IPSEC ipsecnat - IPv6 IPSEC with NAT Traversal (UDP port 4500 encapsulation) gre - Generalized Routing Encapsulation (Protocol 47) l2tp - Layer 2 Tunneling Protocol (UDP port 1701) openvpn - OpenVPN in point-to-point mode openvpnclient - OpenVPN client runs on the firewall openvpnserver - OpenVPN server runs on the firewall generic - Other tunnel type If the type is ipsec, it may be followed by :ah to indicate that the Authentication Headers protocol (51) is used by the tunnel (the default is which means that protocol 51 is not used). NAT traversal is only supported with ESP (protocol 50) so ipsecnat tunnels don't allow the ah option (ipsecnat:noah may be specified but is redundant). If type is openvpn, openvpnclient or openvpnserver it may optionally be followed by ":" and tcp or udp to specify the protocol to be used. If not specified, udp is assumed. Note: At this writing, OpenVPN does not support IPv6. If type is openvpn, openvpnclient or openvpnserver it may optionally be followed by ":" and the port number used by the tunnel. if no ":" and port number are included, then the default port of 1194 will be used. . Where both the protocol and port are specified, the protocol must be given first (e.g., openvpn:tcp:4444). If type is generic, it must be followed by ":" and a protocol name (from /etc/protocols) or a protocol number. If the protocol is tcp or udp (6 or 17), then it may optionally be followed by ":" and a port number. Comments may be attached to Netfilter rules generated from entries in this file through the use of COMMENT lines. These lines begin with the word COMMENT; the remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word COMMENT. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. ZONE - zone The zone of the physical interface through which tunnel traffic passes. This is normally your internet zone. GATEWAY(S) (gateway or gateways) - address-or-range [ , ... ] The IP address of the remote tunnel gateway. If the remote gateway has no fixed address (Road Warrior) then specify the gateway as ::/0. May be specified as a network address and if your kernel and ip6tables include iprange match support then IP address ranges are also allowed. Beginning with Shorewall 4.5.3, a list of addresses or ranges may be given. Exclusion (shorewall6-exclusion (5) ) is not supported. GATEWAY ZONE(S) (gateway_zone or gateway_zones) - [zone[,zone]...] Optional. If the gateway system specified in the third column is a standalone host then this column should contain a comma-separated list of the names of the zones that the host might be in. This column only applies to IPSEC tunnels where it enables ISAKMP traffic to flow through the tunnel to the remote gateway(s). Example Example 1: IPSec tunnel. The remote gateway is 2001:cec792b4:1::44. The tunnel does not use the AH protocol #TYPE ZONE GATEWAY ipsec:noah net 2002:cec792b4:1::44 Example 2: Road Warrior (LapTop that may connect from anywhere) where the "gw" zone is used to represent the remote LapTop #TYPE ZONE GATEWAY GATEWAY ZONES ipsec net ::/0 gw Example 3: Host 2001:cec792b4:1::44 is a standalone system connected via an ipsec tunnel to the firewall system. The host is in zone gw. #TYPE ZONE GATEWAY GATEWAY ZONES ipsec net 2001:cec792b4:1::44 gw Example 4: OPENVPN tunnel. The remote gateway is 2001:cec792b4:1::44 and openvpn uses port 7777. #TYPE ZONE GATEWAY GATEWAY ZONES openvpn:7777 net 2001:cec792b4:1::44 Example 8: You have a tunnel that is not one of the supported types. Your tunnel uses UDP port 4444. The other end of the tunnel is 2001:cec792b4:1::44. #TYPE ZONE GATEWAY GATEWAY ZONES generic:udp:4444 net 2001:cec792b4:1::44 FILES /etc/shorewall6/tunnels See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-zones.xml0000644000175000017500000004211412222401136023043 0ustar teastepteastep shorewall6-zones 5 zones Shorewall6 zone declaration file /etc/shorewall6/zones Description The /etc/shorewall6/zones file declares your network zones. You specify the hosts in each zone through entries in /etc/shorewall6/interfaces or /etc/shorewall6/hosts. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ZONE - zone[:parent-zone[,parent-zone]...] Name of the zone. The names "all", "none", "SOURCE" and "DEST" are reserved and may not be used as zone names. The maximum length of a zone name is determined by the setting of the LOGFORMAT option in shorewall6.conf(5). With the default LOGFORMAT, zone names can be at most 5 characters long.
The maximum length of an iptables log prefix is 29 bytes. As explained in shorewall6.conf (5), the default LOGPREFIX formatting string is “Shorewall:%s:%s:” where the first %s is replaced by the chain name and the second is replaced by the disposition. The default formatting string has 12 fixed characters ("Shorewall" and three colons). The longest of the standard dispositions are ACCEPT and REJECT which have 6 characters each. The canonical name for the chain containing the rules for traffic going from zone 1 to zone 2 is "<zone 1>2<zone 2>". So if M is the maximum zone name length, such chains can have length 2*M + 1. 12 + 6 + 2*M + 1 = 29 which reduces to 2*M = 29 - 12 - 6 - 1 = 10 or M = 5
The order in which Shorewall6 matches addresses from packets to zones is determined by the order of zone declarations. Where a zone is nested in one or more other zones, you may either ensure that the nested zone precedes its parents in this file, or you may follow the (sub)zone name by ":" and a comma-separated list of the parent zones. The parent zones must have been declared in earlier records in this file. See shorewall6-nesting(5) for additional information. Example: #ZONE TYPE OPTIONS IN OPTIONS OUT OPTIONS a ipv6 b ipv6 c:a,b ipv6 Currently, Shorewall6 uses this information to reorder the zone list so that parent zones appear after their subzones in the list. The IMPLICIT_CONTINUE option in shorewall6.conf(5) can also create implicit CONTINUE policies to/from the subzone. Where an ipsec zone is explicitly included as a child of an ipv6 zone, the ruleset allows CONTINUE policies (explicit or implicit) to work as expected. In the future, Shorewall6 may make additional use of nesting information.
TYPE ipv6 This is the standard Shorewall6 zone type and is the default if you leave this column empty or if you enter "-" in the column. Communication with some zone hosts may be encrypted. Encrypted hosts are designated using the 'ipsec' option in shorewall6-hosts(5). ipsec (or ipsec6) Communication with all zone hosts is encrypted. Your kernel and ip6tables must include policy match support. firewall Designates the firewall itself. You must have exactly one 'firewall' zone. No options are permitted with a 'firewall' zone. The name that you enter in the ZONE column will be stored in the shell variable $FW which you may use in other configuration files to designate the firewall zone. bport (or bport6) The zone is associated with one or more ports on a single bridge. vserver Added in Shorewall 4.4.11 Beta 2 - A zone composed of Linux-vserver guests. The zone contents must be defined in shorewall6-hosts (5). Vserver zones are implicitly handled as subzones of the firewall zone. loopback Added in Shorewall 4.5.17. Normally, Shorewall treats the loopback interface (lo) in the following way: By default, all traffic through the interface is ACCEPTed. If a $FW -> $FW policy is defined or $FW -> $FW rules are defined, they are placed in a chain named ${FW}2${F2} or ${FW}-${FW} (e.g., 'fw2fw' or 'fw-fw' ) depending on the ZONE2ZONE setting in shorewall6.conf(5). $FW -> $FW traffic is only filtered in the OUTPUT chain. By defining a loopback zone and associating it with the loopback interface in shorewall-interfaces(5), you can effect a slightly different model. Suppose that the loopback zone name is 'local'; then: Both $FW -> local and local -> $FW chains are created. The $FW -> local and local -> $FW policies may be different. Both $FW -> local and local -> $FW rules may be specified. Rules to/from the loopback zone and any zone other than the firewall zone are ignored with a warning. loopback zones may be nested within other loopback zones. local Added in Shorewall 4.5.17. local is the same as ipv6 with the exception that the zone is only accessible from the firewall and vserver zones. OPTIONS, IN OPTIONS and OUT OPTIONS (options, in_options, out_options) - [option[,option]...] A comma-separated list of options. With the exception of the and options, these only apply to TYPE zones. blacklist Added in Shorewall 4.4.13. May not be specified for firewall or vserver zones. When specified in the IN_OPTIONS column, causes all traffic from this zone to be passed against the src entries in shorewall6-blacklist(5). When specified in the OUT_OPTIONS column, causes all traffic to this zone to be passed against the dst entries in shorewall6-blacklist(5). Specifying this option in the OPTIONS column is equivalent to entering it in both of the IN_OPTIONS and OUT_OPTIONS column. dynamic_shared Added in Shorewall 4.5.9. May only be specified in the OPTIONS column and indicates that only a single ipset should be created for this zone if it has multiple dynamic entries in shorewall6-hosts(5). Without this option, a separate ipset is created for each interface. reqid=number where number is specified using setkey(8) using the 'unique:number option for the SPD level. spi=<number> where number is the SPI of the SA used to encrypt/decrypt packets. proto=ah|esp|ipcomp IPSEC Encapsulation Protocol mss=number sets the MSS field in TCP packets. If you supply this option, you should also set FASTACCEPT=No in shorewall6.conf(5) to insure that both the SYN and SYN,ACK packets have their MSS field adjusted. mode=transport|tunnel IPSEC mode tunnel-src=address[/mask] only available with mode=tunnel tunnel-dst=address[/mask] only available with mode=tunnel strict Means that packets must match all rules. next Separates rules; can only be used with strict The options in the OPTIONS column are applied to both incoming and outgoing traffic. The IN OPTIONS are applied to incoming traffic (in addition to OPTIONS) and the OUT OPTIONS are applied to outgoing traffic. If you wish to leave a column empty but need to make an entry in a following column, use "-".
FILES /etc/shorewall6/zones See ALSO http://www.shorewall.net/Multiple_Zones.html. http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-nesting(8), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-stoppedrules.xml0000644000175000017500000001532512222401136024442 0ustar teastepteastep shorewall6-stoppedrules 5 stoppedrules The Shorewall file that governs what traffic flows through the firewall while it is in the 'stopped' state. /etc/shorewall6/stoppedrules Description This file is used to define the hosts that are accessible when the firewall is stopped or is being stopped. Changes to this file do not take effect until after the next shorewall start, shorewall restart, or command. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ACTION - Determines the disposition of the packet. means that the packet will be accepted. indicates that no conntrack entry should be created for the packet. does not imply . SOURCE - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,address]...] matches packets originating on the firewall itself, while interface specifies packets arriving on the named interface. This column may also include a comma-separated list of IP/subnet addresses. If your kernel and iptables include iprange match support, IP address ranges are also allowed. Ipsets and exclusion are also supported. When or interface are specified, the list must be preceded by a colon (":"). If left empty or supplied as "-", ::/0 is assumed. DEST - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,address]...] matches packets addressed the firewall itself, while interface specifies packets arriving on the named interface. Neither may be specified if the target is . This column may also include a comma-separated list of IP/subnet addresses. If your kernel and iptables include iprange match support, IP address ranges are also allowed. Ipsets and exclusion are also supported. When or interface are specified, the list must be preceded by a colon (":"). If left empty or supplied as "-", ::/0 is assumed. PROTO (Optional) ‒ protocol-name-or-number[,...] Protocol. Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. DEST PORT(S) (dport) ‒ service-name/port-number-list Optional. A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. SOURCE PORT(S) (sport) ‒ service-name/port-number-list Optional. A comma-separated list of port numbers and/or service names from /etc/services. May also include port ranges of the form low-port:high-port if your kernel and iptables include port range support. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel. FILES /etc/shorewall6/stoppedrules See ALSO http://shorewall.net/starting_and_stopping_shorewall.htm http://shorewall.net/configuration_file_basics.htm#Pairs shorewall(8), shorewall-accounting(5), shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5), shorewall-params(5), shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-policy.xml0000644000175000017500000003251612222401136023211 0ustar teastepteastep shorewall6-policy 5 policy shorewall6 policy file /etc/shorewall6/policy Description This file defines the high-level policy for connections between zones defined in shorewall6-zones(5). The order of entries in this file is important This file determines what to do with a new connection request if we don't get a match from the /etc/shorewall6/rules file . For each source/destination pair, the file is processed in order until a match is found ("all" will match any client or server). Intra-zone policies are pre-defined For $FW and for all of the zones defined in /etc/shorewall6/zones, the POLICY for connections from the zone to itself is ACCEPT (with no logging or TCP connection rate limiting but may be overridden by an entry in this file. The overriding entry must be explicit (specifying the zone name on both SOURCE and DEST) or it must use "all+ or it must use "all+" (Shorewall 4.5.17 or later). Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall6.conf, then the implicit policy to/from any sub-zone is CONTINUE. These implicit CONTINUE policies may also be overridden by an explicit entry in this file. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). SOURCE - zone|$FW|all|all+ Source zone. Must be the name of a zone defined in shorewall-zones(5), $FW, "all" or "all+". Support for "all+" was added in Shorewall 4.5.17. "all" does not override the implicit intra-zone ACCEPT policy while "all+" does. DEST - zone|$FW|all|all+ Destination zone. Must be the name of a zone defined in shorewall-zones(5), $FW, "all" or "all+". If the DEST is a bport zone, then the SOURCE must be "all", "all+", another bport zone associated with the same bridge, or it must be an ipv4 zone that is associated with only the same bridge. Support for "all+" was added in Shorewall 4.5.17. "all" does not override the implicit intra-zone ACCEPT policy while "all+" does. POLICY - {ACCEPT|DROP|REJECT|CONTINUE|QUEUE|NFQUEUE[(queuenumber)]|NONE}[:{default-action-or-macro|None}] Policy if no match from the rules file is found. If the policy is neither CONTINUE nor NONE then the policy may be followed by ":" and one of the following: The word "None" or "none". This causes any default action defined in shorewall.conf(5) to be omitted for this policy. The name of an action. The action will be invoked before the policy is enforced. Actions can have parameters specified. Beginning with Shorewall 4.5.10, the action name can be followed optionally by a colon and a log level. The level will be applied to each rule in the action or body that does not already have a log level. Possible actions are: ACCEPT Accept the connection. DROP Ignore the connection request. REJECT For TCP, send RST. For all other, send an "unreachable" ICMP. QUEUE Queue the request for a user-space application such as Snort-inline. NFQUEUE Queue the request for a user-space application using the nfnetlink_queue mechanism. If a queuenumber is not given, queue zero (0) is assumed. CONTINUE Pass the connection request past any other rules that it might also match (where the source or destination zone in those rules is a superset of the SOURCE or DEST in this policy). See shorewall6-nesting(5) for additional information. NONE Assume that there will never be any packets from this SOURCE to this DEST. shorewall6 will not create any infrastructure to handle such packets and you may not have any rules with this SOURCE and DEST in the /etc/shorewall6/rules file. If such a packet is received, the result is undefined. NONE may not be used if the SOURCE or DEST columns contain the firewall zone ($FW) or "all". LOG LEVEL (loglevel) - [log-level|NFLOG] Optional - if supplied, each connection handled under the default POLICY is logged at that level. If not supplied, no log message is generated. See syslog.conf(5) for a description of log levels. You may also specify NFLOG (must be in upper case). This will log to the NFLOG target and will send to a separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html). If you don't want to log but need to specify the following column, place "-" here. BURST:LIMIT (limit) - [{s|d}:[[name]:]]]rate/{second|minute}[:burst] If passed, specifies the maximum TCP connection rate and the size of an acceptable burst. If not specified, TCP connections are not limited. If the burst parameter is omitted, a value of 5 is assumed. When or is specified, the rate applies per source IP address or per destination IP address respectively. The name may be chosen by the user and specifies a hash table to be used to count matching connections. If not give, the name shorewall is assumed. Where more than one POLICY specifies the same name, the connections counts for the policies are aggregated and the individual rates apply to the aggregated count. CONNLIMIT - limit[:mask] May be used to limit the number of simultaneous connections from each individual host to limit connections. While the limit is only checked on connections to which this policy could apply, the number of current connections is calculated over all current connections from the SOURCE host. By default, the limit is applied to each host individually but can be made to apply to networks of hosts by specifying a mask. The mask specifies the width of a VLSM mask to be applied to the source address; the number of current connections is then taken over all hosts in the subnet source-address/mask. Example All connections from the local network to the internet are allowed All connections from the internet are ignored but logged at syslog level KERNEL.INFO. All other connection requests are rejected and logged at level KERNEL.INFO. #SOURCE DEST POLICY LOG BURST:LIMIT # LEVEL loc net ACCEPT net all DROP info # # THE FOLLOWING POLICY MUST BE LAST # all all REJECT info FILES /etc/shorewall6/policy See ALSO http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-ipsec(5), shorewall6-maclist(5), shorewall6-masq(5), shorewall6-nat(5), shorewall6-netmap(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-proxyarp(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-accounting.xml0000644000175000017500000007744412222401136024055 0ustar teastepteastep shorewall6-accounting 5 accounting Shorewall6 Accounting file /etc/shorewall6/accounting Description Accounting rules exist simply to count packets and bytes in categories that you define in this file. You may display these rules and their packet and byte counters using the shorewall6 show accounting command. Beginning with Shorewall 4.4.18, the accounting structure can be created with three root chains: accountin: Rules that are valid in the INPUT chain (may not specify an output interface). accountout: Rules that are valid in the OUTPUT chain (may not specify an input interface or a MAC address). accounting: Other rules. The new structure is enabled by sectioning the accounting file in a manner similar to the rules file. The sections are INPUT, OUTPUT and FORWARD and must appear in that order (although any of them may be omitted). The first non-commentary record in the accounting file must be a section header when sectioning is used. If sections are not used, the Shorewall rules compiler cannot detect certain violations of netfilter restrictions. These violations can result in run-time errors such as the following:
ip6tables-restore v1.4.13: Can't use -o with INPUT
Beginning with Shorewall 4.4.20, the ACCOUNTING_TABLE setting was added to shorewall.conf and shorewall6.conf. That setting determines the Netfilter table (filter or mangle) where the accounting rules are added. When ACCOUNTING_TABLE=mangle is specified, the available sections are PREROUTING, INPUT, OUTPUT, FORWARD and POSTROUTING. Section headers have the form: section-name When sections are enabled: A jump to a user-defined accounting chain must appear before entries that add rules to that chain. This eliminates loops and unreferenced chains. An output interface may not be specified in the PREROUTING and INPUT sections. In the OUTPUT and POSTROUTING sections: An input interface may not be specified Jumps to a chain defined in the INPUT or PREROUTING sections that specifies an input interface are prohibited MAC addresses may not be used Jump to a chain defined in the INPUT or PREROUTING section that specifies a MAC address are prohibited. The default value of the CHAIN column is: accountin in the INPUT section accountout in the OUTPUT section accountfwd in the FORWARD section accountpre in the PREROUTING section accountpost in the POSTROUTING section Traffic addressed to the firewall goes through the rules defined in the INPUT section. Traffic originating on the firewall goes through the rules defined in the OUTPUT section. Traffic being forwarded through the firewall goes through the rules from the FORWARD sections. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). ACTION - {COUNT|DONE|chain[:{COUNT|JUMP}]|[?]COMMENT comment} What to do when a matching packet is found. COUNT Simply count the match and continue with the next rule DONE Count the match and don't attempt to match any other accounting rules in the chain specified in the CHAIN column. chain[:COUNT] Where chain is the name of a chain; shorewall6 will create the chain automatically if it doesn't already exist. If a second chain is mentioned in the CHAIN column, then a jump from this second chain to chain is created. If no chain is named in the CHAIN column, then a jump from the default chain to chain is created. If :COUNT is included, a counting rule matching this entry will be added to chain. The chain may not exceed 29 characters in length and may be composed of letters, digits, dash ('-') and underscore ('_'). chain:JUMP Like the previous option without the :COUNT part. INLINE Added in Shorewall 4.5.16. Allows free form ip6tables matches to be specified following a ';'. In the generated ip6tables rule(s), the free form matches will follow any matches that are generated by the column contents. NFACCT({object[!]}[,...]) Added in Shorewall 4.5.7. Provides a form of accounting that survives shorewall stop/shorewall start and shorewall restart. Requires the NFaccnt Match capability in your kernel and iptables. object names an nfacct object (see man nfaccnt(8)). Multiple rules can specify the same object; all packets that match any of the rules increment the packet and bytes count of the object. Prior to Shorewall 4.5.16, only one object could be specified. Beginning with Shorewall 4.5.16, an arbitrary number of objects may be given. With Shorewall 4.5.16 or later, an nfacct object in the list may optionally be followed by ! to indicate that the nfacct object will be incremented unconditionally for each packet. When ! is omitted, the object will be incremented only if all of the matches in the rule succeed. NFLOG[(nflog-parameters)] - Added in Shorewall-4.4.20. Causes each matching packet to be sent via the currently loaded logging back end (usually nfnetlink_log) where it is available to accounting daemons through a netlink socket. [?]COMMENT The remainder of the line is treated as a comment which is attached to subsequent rules until another COMMENT line is found or until the end of the file is reached. To stop adding comments to rules, use a line with only the word COMMENT. Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT and is preferred. CHAIN - {-|chain} The name of a chain. If specified as - the accounting chain is assumed when the file is un-sectioned. When the file is sectioned, the default is one of accountin, accountout, etc. depending on the section. This is the chain where the accounting rule is added. The chain will be created if it doesn't already exist. The chain may not exceed 29 characters in length. SOURCE - {-|any|all|interface|interface:address|address} Packet Source. The name of an interface, an address (host or net) or an interface name followed by ":" and a host or net address. An ipset name is also accepted as an address. DESTINATION (dest) - {-|any|all|interface|interfaceaddress|address} Packet Destination. Format same as SOURCE column. PROTOCOL (proto) - {-|any|all|protocol-name|protocol-number|ipp2p[:{udp|all}]} A protocol-name (from protocols(5)), a protocol-number, ipp2p, ipp2p:udp or ipp2p:all Beginning with Shorewall 4.5.12, this column can accept a comma-separated list of protocols. DEST PORT(S) (dport) - {-|any|all|ipp2p-option|port-name-or-number[,port-name-or-number]...} Destination Port number. Service name from services(5) or port number. May only be specified if the protocol is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136). You may place a comma-separated list of port names or numbers in this column if your kernel and ip6tables include multi-port match support. If the PROTOCOL is ipp2p then this column must contain an ipp2p-option ("ip6tables -m ipp2p --help") without the leading "--". If no option is given in this column, ipp2p is assumed. SOURCE PORT(S) (sport) - {-|any|all|port-name-or-number[,port-name-or-number]...} Service name from services(5) or port number. May only be specified if the protocol is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE (136). You may place a comma-separated list of port numbers in this column if your kernel and ip6tables include multi-port match support. Beginning with Shorewall 4.5.15, you may place '=' in this column, provided that the DEST PORT(S) column is non-empty. This causes the rule to match when either the source port or the destination port in a packet matches one of the ports specified in DEST PORTS(S). Use of '=' requires multi-port match in your iptables and kernel. USER/GROUP (user) - [!][user-name-or-number][:group-name-or-number][+program-name] This column may only be non-empty if the CHAIN is OUTPUT. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group specified (or is NOT running under that id if "!" is given). Examples: joe program must be run by joe :kids program must be run by a member of the 'kids' group !:kids program must not be run by a member of the 'kids' group +upnpd #program named upnpd The ability to specify a program name was removed from Netfilter in kernel version 2.6.14. MARK - [!]value[/mask][:C] Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. ! Inverts the test (not equal) value Value of the packet or connection mark. mask A mask to be applied to the mark before testing. :C Designates a connection mark. If omitted, the packet mark's value is tested. IPSEC - option-list (Optional - Added in Shorewall 4.4.13 but broken until 4.5.4.1 ) The option-list consists of a comma-separated list of options from the following list. Only packets that will be encrypted or have been decrypted via an SA that matches these options will have their source address changed. May only be specified when sections are used. reqid=number where number is specified using setkey(8) using the 'unique:number option for the SPD level. spi=<number> where number is the SPI of the SA used to encrypt/decrypt packets. proto=ah|esp|ipcomp IPSEC Encapsulation Protocol mss=number sets the MSS field in TCP packets mode=transport|tunnel IPSEC mode tunnel-src=address[/mask] only available with mode=tunnel tunnel-dst=address[/mask] only available with mode=tunnel strict Means that packets must match all rules. next Separates rules; can only be used with strict yes or ipsec When used by itself, causes all traffic that will be encrypted/encapsulated or has been decrypted/un-encapsulated to match the rule. no or none When used by itself, causes all traffic that will not be encrypted/encapsulated or has been decrypted/un-encapsulated to match the rule. in May only be used in the FORWARD section and must be the first or the only item the list. Indicates that matching packets have been decrypted in input. out May only be used in the FORWARD section and must be the first or the only item in the list. Indicates that matching packets will be encrypted on output. If this column is non-empty and sections are not used, then: A chain NAME appearing in the ACTION column must be a chain branched either directly or indirectly from the accipsecin or accipsecout chain. The CHAIN column must contain either accipsecin or accipsecout or a chain branched either directly or indirectly from those chains. These rules will NOT appear in the accounting chain. HEADERS - [!][any:|exactly:]header-list (Optional - Added in Shorewall 4.4.15) The header-list consists of a comma-separated list of headers from the following list. auth, ah, or 51 Authentication Headers extension header. esp, or 50 Encrypted Security Payload extension header. hop, hop-by-hop or 0 Hop-by-hop options extension header. route, ipv6-route or 41 IPv6 Route extension header. frag, ipv6-frag or 44 IPv6 fragmentation extension header. none, ipv6-nonxt or 59 No next header proto, protocol or 255 Any protocol header. If any: is specified, the rule will match if any of the listed headers are present. If exactly: is specified, the will match packets that exactly include all specified headers. If neither is given, any: is assumed. If ! is entered, the rule will match those packets which would not be matched when ! is omitted. In all of the above columns except ACTION and CHAIN, the values -, any and all may be used as wildcards. Omitted trailing columns are also treated as wildcards.
FILES /etc/shorewall6/accounting See ALSO http://shorewall.net/Accounting.html http://shorewall.net/shorewall_logging.html http://shorewall.net/configuration_file_basics.htm#Pairs shorewall6(8), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-params.xml0000644000175000017500000000772512222401136023201 0ustar teastepteastep shorewall6-netmap(5),shorewall6-params 5 params Shorewall6 parameters file /etc/shorewall6/params Description Assign any shell variables that you need in this file. The file is always processed by /bin/sh or by the shell specified through SHOREWALL_SHELL in shorewall6.conf (5) so the full range of shell capabilities may be used. 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 shorewall6.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 VERBOSE VERBOSE_OFFSET VERSION Example params file: NET_IF=eth0 NET_OPTIONS=dhcp,nosmurfs Example shorewall6-interfaces(5) file. ZONE INTERFACE BROADCAST OPTIONS net $NET_IF - $NET_OPTIONS This is the same as if the interfaces file had contained: ZONE INTERFACE BROADCAST OPTIONS net eth0 - dhcp,nosmurfs FILES /etc/shorewall6/params See ALSO http://www.shorewall.net/configuration_file_basics.htm#Variables shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5) shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcdevices.xml0000644000175000017500000003003312222401136023653 0ustar teastepteastep shorewall6-tcdevices 5 tcdevices Shorewall6 Traffic Shaping Devices file /etc/shorewall6/tcdevices Description Entries in this file define the bandwidth for interfaces on which you want traffic shaping to be enabled. If you do not plan to use traffic shaping for a device, don't put it in here as it limits the throughput of that device to the limits you set here. A note on the bandwidth definitions used in this file: don't use a space between the integer value and the unit: 30kbit is valid while 30 kbit is not. you can use one of the following units: kbps Kilobytes per second. mbps Megabytes per second. kbit Kilobits per second. mbit Megabits per second. bps or number Bytes per second. Only whole integers are allowed. The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax). INTERFACE - [number:]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 http://www.shorewall.net/FAQ.htm#faq18 You may NOT specify wildcards here, e.g. if you have multiple ppp interfaces, you need to put them all in here! If the device doesn't exist, a warning message will be issued during "shorewall6 [re]start" and "shorewall6 refresh" and traffic shaping configuration will be skipped for that device. Shorewall6 assigns a sequential interface number to each interface (the first entry in the file is interface 1, the second is interface 2 and so on) Beginning with Shorewall6-perl 4.1.6, you can explicitly specify the interface number by prefixing the interface name with the number and a colon (":"). Example: 1:eth0. IN-BANDWIDTH (in_bandwidth) - {-|bandwidth[:burst]|~bandwidth[:interval:decay_interval]} The incoming bandwidth of that interface. Please note that you are not able to do traffic shaping on incoming traffic, as the traffic is already received before you could do so. But this allows you to define the maximum traffic allowed for this interface in total, if the rate is exceeded, the 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 to zero in which case Shorewall will not create an ingress qdisc.Must be set to zero if the REDIRECTED INTERFACES column is non-empty. The optional burst option was added in Shorewall 4.4.18. The default burst is 10kb. A larger burst can help make the bandwidth more accurate; often for fast lines, the enforced rate is well below the specified bandwidth. What is described above creates a rate/burst policing filter. Beginning with Shorewall 4.4.25, a rate-estimated policing filter may be configured instead. Rate-estimated filters should be used with Ethernet adapters that have Generic Receive Offload enabled by default. See Shorewall FAQ 97a. 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. OUT-BANDWIDTH (out_bandwidth) - bandwidth 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 in shorewall6-tcclasses(5). Outgoing traffic above this rate will be dropped. OPTIONS - {-|{classify|htb|hfsc|linklayer={ethernet|atm|adsl}|tsize=tsize|mtu=mtu|mpu=mpu|overhead=overhead} ,...} ― When specified, Shorewall will not generate tc or Netfilter rules to classify traffic based on packet marks. You must do all classification using CLASSIFY rules in shorewall-tcrules(5). - Use the Hierarchical Token Bucket queuing discipline. This is the default. - Shorewall normally uses the Hierarchical Token Bucket queuing discipline. When is specified, the Hierarchical Fair Service Curves discipline is used instead(see tc-hfsc (7)). 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 (redirect) - [interface[,interface]...] Added in Shorewall6-perl 4.1.6. May only be specified if the interface in the INTERFACE column is an Intermediate Frame Block (IFB) device. Causes packets that enter each listed interface to be passed through the egress filters defined for this device, thus providing a form of incoming traffic shaping. When this column is non-empty, the classify option is assumed.
Examples Example 1: 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 #INTERFACE IN-BANDWIDTH OUT-BANDWIDTH OPTIONS REDIRECTED # INTERFACES 1:ppp0 6000kbit 500kbit FILES /etc/shorewall6/tcdevices See ALSO tc-hfsc (7) http://shorewall.net/traffic_shaping.htm http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt shorewall6(8), shorewall6-accounting(5), shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/PortKnocking.xml0000644000175000017500000001457112222401136020356 0ustar teastepteastep
Port Knocking and Other Uses of 'Recent Match' Tom Eastep 2005 2006 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. The techniques described in this article were superceded in Shorewall 4.5.19 with the introduction of Shorewall Events. The feature described in this article require 'Recent Match' in your iptables and kernel. See the output of shorewall show capabilities to see if you have that match.
What is Port Knocking? Port knocking is a technique whereby attempting to connect to port A enables access to port B from that same host. For the example on which this article is based, see http://www.soloport.com/iptables.html which should be considered to be part of this documentation.
Implementing Port Knocking in Shorewall In order to implement this solution, your iptables and kernel must support the 'recent match' extension (see FAQ 42). In this example: Attempting to connect to port 1600 enables SSH access. Access is enabled for 60 seconds. Attempting to connect to port 1601 disables SSH access (note that in the article linked above, attempting to connect to port 1599 also disables access. This is an port scan defence as explained in the article). To implement that approach: Add an action named SSHKnock (see the Action documentation). Leave the action.SSHKnock file empty. Create /etc/shorewall/SSHKnock with the following contents.use Shorewall::Chains; if ( $level ) { log_rule_limit( $level, $chainref, 'SSHKnock', 'ACCEPT', '', $tag, 'add', '-p tcp --dport 22 -m recent --rcheck --name SSH ' ); log_rule_limit( $level, $chainref, 'SSHKnock', 'DROP', '', $tag, 'add', '-p tcp ! --dport 22 ' ); } add_rule( $chainref, '-p tcp --dport 22 -m recent --rcheck --seconds 60 --name SSH -j ACCEPT' ); add_rule( $chainref, '-p tcp --dport 1599 -m recent --name SSH --remove -j DROP' ); add_rule( $chainref, '-p tcp --dport 1600 -m recent --name SSH --set -j DROP' ); add_rule( $chainref, '-p tcp --dport 1601 -m recent --name SSH --remove -j DROP' ); 1; Now if you want to protect SSH access to the firewall from the Internet, add this rule in /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) SSHKnock net $FW tcp 22,1599,1600,1601 If you want to log the DROPs and ACCEPTs done by SSHKnock, you can just add a log level as in: #ACTION SOURCE DEST PROTO DEST PORT(S) SSHKnock:info net $FW tcp 22,1599,1600,1601 Assume that you forward port 22 from external IP address 206.124.146.178 to internal system 192.168.1.5. In /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST DNAT- net loc: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.178 You can use SSHKnock with DNAT on earlier releases provided that you omit the ORIGINAL DEST entry on the second SSHKnock rule. This rule will be quite secure provided that you specify 'routefilter' on your external interface and have NULL_ROUTE_RFC1918=Yes in shorewall.conf. For another way to implement Port Knocking, see the Manual Chain documentation.
Limiting Per-IP Connection Rate This information has been moved to the Actions article.
shorewall-docs-xml-4.5.21/Shorewall_and_Aliased_Interfaces.xml0000644000175000017500000003572312222401136024317 0ustar teastepteastep
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 DEST PORT(S) 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 DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST DNAT net loc:192.168.1.3 tcp 80 - 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 Similarly, you want SMTP traffic from local system 192.168.1.22 to have source IP 206.124.146.178:#INTERFACE SUBNET ADDRESS PROTO DEST PORT(S) eth0 192.168.1.22 206.124.146.178 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.178Shorewall 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 SUBNET ADDRESS eth0:0 192.168.1.0/24 206.124.146.178-206.124.146.180 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 DEST PORT(S) 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 BROADCAST 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 BROADCAST 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-4.5.21/GettingStarted.xml0000644000175000017500000001520412222401136020670 0ustar teastepteastep
Getting Started with Shorewall Tom Eastep 2006 2007 2010 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. Do not attempt to install Shorewall on a remote system. You are virtually assured to lock yourself out. Please read this short article first. Introduction to Shorewall Now, install Shorewall. Next, read the QuickStart Guide that is appropriate for your configuration: If you just want to protect a system: (Requires Shorewall 4.4.12-Beta3 or later) Universal configuration -- requires no configuration to protect a single system. If you have only one public IP address: Standalone Linux System with a single network interface (if you are running Shorewall 4.4.12 Beta 3 or later, use the Universal configuration instead). Two-interface Linux System acting as a firewall/router for a small local network Three-interface Linux System acting as a firewall/router for a small local network and a DMZ. If you have more than one public IP address: The Shorewall Setup Guide outlines the steps necessary to set up a firewall where there are multiple public IP addresses involved or if you want to learn more about Shorewall than is explained in the single-address guides above. The following articles are also recommended reading for newcomers. Configuration File Basics
Man Pages Using MAC Addresses in Shorewall Comments in configuration files Using Shell Variables Attach Comment to Netfilter Rules Using DNS Names Line Continuation Complementing an IP address or Subnet INCLUDE Directive IP Address Ranges Port Numbers/Service Names Shorewall Configurations (making a test configuration) Port Ranges
Operating Shorewall and Shorewall Lite contains a lot of useful operational hints. PPPPPPPS ( or, Paul's Principles for Practical Provision of Packet Processing with Shorewall ) http://linuxman.wikispaces.com/PPPPPPS
shorewall-docs-xml-4.5.21/Shorewall-perl.xml0000644000175000017500000013734212222401136020650 0ustar teastepteastep
Shorewall-perl Tom Eastep 2007 2009 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.
Shorewall-perl - What is it? Shorewall-perl was released as a companion product to Shorewall in Shorewall 4.0.0. Shorewall-perl contained a re-implementation of the Shorewall compiler written in Perl. The advantages of using Shorewall-perl over Shorewall-shell (the shell-based compiler included in earlier Shorewall 3.x releases) were: The Shorewall-perl compiler was much faster. The script generated by the compiler used iptables-restore to instantiate the Netfilter configuration. So it ran much faster than the script generated by the Shorewall-shell compiler and did not stop new connections during shorewall restart. The Shorewall-perl compiler did more thorough checking of the configuration than the Shorewall-shell compiler did. The error messages produced by the compiler were better, more consistent and always included the file name and line number where the error was detected. Going forward, the Shorewall-perl compiler got all enhancements; the Shorewall-shell compilerl only got those enhancements that were easy to retrofit. Beginning with Shorewall 4.3.5, Shorewall-perl is an integral part of Shorewall and support for Shorewall-shell has been discontinued.
Shorewall-perl - The down side While there are significant advantages to using Shorewall-perl, there are also disadvantages.
Incompatibilities There are a number of incompatibilities between the Shorewall-perl compiler and the earlier one. The Perl-based compiler requires multiport match in your kernel and iptables. BRIDGING=Yes is not supported. The kernel code necessary to support this option was removed in Linux kernel 2.6.20. Alternative bridge support is provided by Shorewall-perl. DYNAMIC_ZONES=Yes is not supported in Shorewall-perl 4.2. Use an ipset to define your dytnamic zones. In Shorewall 4.4, dynamic zone support based on ipsets was added to Shorewall. The BROADCAST column in the interfaces file is essentially unused if your kernel/iptables has Address Type Match support. If that support is present and you enter anything in this column but '-' or 'detect', you will receive a warning. The 'refresh' command is now similar to restart with the exceptions that: The command fails if Shorewall is not running. A directory name cannot be specified in the command. The refresh command does not alter the Netfilter configuration except for the static blacklist (it also refreshes the mangle table, beginning with Shorewall 4.2.0). With the shell-based compiler, extension scripts were copied into the compiled script and executed at run-time. In many cases, this approach doesn't work with Shorewall Perl because (almost) the entire rule set is built by the compiler. As a result, Shorewall-perl runs some extension scripts at compile-time rather than at run-time. Because the compiler is written in Perl, your extension scripts from earlier versions will no longer work. The following table summarizes when the various extension scripts are run: Compile-time (Must be written in Perl) Run-time Eliminated initdone clear continue maclog init Per-chain (including those associated with actions) start started stop stopped tcclear Compile-time extension scripts are executed using the Perl 'eval `cat <file>`' mechanism. Be sure that each script returns a 'true' value; otherwise, the Shorewall-perl compiler will assume that the script failed and will abort the compilation. When a script is invoked, the $chainref scalar variable will usually hold a reference to a chain table entry. $chainref->{name} contains the name of the chain $chainref->{table} holds the table name To add a rule to the chain: add_rule $chainref, the-rule Where the rule is a scalar argument holding the rule text. Do not include "-A chain-name" Example: add_rule $chainref, '-j ACCEPT'; To insert a rule into the chain: insert_rule $chainref, rulenum, the-rule The log_rule_limit function works like it does in the shell compiler with three exceptions: You pass the chain reference rather than the name of the chain. The commands are 'add' and 'insert' rather than '-A' and '-I'. There is only a single "pass as-is to iptables" argument (so you must quote that part) Example: log_rule_limit 'info' , $chainref , $chainref->{name}, 'DROP' , '', #Limit '' , #Log tag 'add' '-p tcp '; Here is an example of an actual initdone script used with Shorewall 3.4:run_iptables -t mangle -I PREROUTING -p esp -j MARK --set-mark 0x50 run_iptables -t filter -I INPUT -p udp --dport 1701 -m mark --mark 0x50 -j ACCEPT run_iptables -t filter -I OUTPUT -p udp --sport 1701 -j ACCEPT Here is the corresponding script used with Shorewall-perl:use Shorewall::Chains; insert_rule $mangle_table->{PREROUTING}, 1, "-p esp -j MARK --set-mark 0x50"; insert_rule $filter_table->{INPUT}, 1, "-p udp --dport 1701 -m mark --mark 0x50 -j ACCEPT"; insert_rule $filter_table->{OUTPUT}, 1, "-p udp --sport 1701 -j ACCEPT"; 1; The initdone script is unique because the $chainref variable is not set before the script is called. The above script illustrates how the $mangle_table, $filter_table, and $nat_table references can be used to add or insert rules in arbitrary chains. The /etc/shorewall/tos file now has zone-independent SOURCE and DEST columns as do all other files except the rules and policy files. The SOURCE column may be one of the following: [all:]<address>[,...] [all:]<interface>[:<address>[,...]] $FW[:<address>[,...]] The DEST column may be one of the following: [all:]<address>[,...] [all:]<interface>[:<address>[,...]] This is a permanent change. The old zone-based rules have never worked right and this is a good time to replace them. I've tried to make the new syntax cover the most common cases without requiring change to existing files. In particular, it will handle the tos file released with Shorewall 1.4 and earlier. Shorewall-perl insists that ipset names begin with a letter and be composed of alphanumeric characters and underscores (_). When used in a Shorewall configuration file, the name must be preceded by a plus sign (+) as with the shell-based compiler. From Shorewall-perl 4.0.0 - Shorewall 4.4.5, Shorewall was out of the ipset load/reload business with the exception of ipsets used for dynamic zones:
With scripts generated by the Perl-based Compiler, the Netfilter rule set is never cleared. That means that there is no opportunity for Shorewall to load/reload your ipsets since that cannot be done while there are any current rules using ipsets. So: Your ipsets must be loaded before Shorewall starts. You are free to try to do that with the following code in /etc/shorewall/init (it works for me; your mileage may vary): if [ "$COMMAND" = start ]; then ipset -U :all: :all: ipset -U :all: :default: ipset -F ipset -X ipset -R < /etc/shorewall/ipsets fi The file /etc/shorewall/ipsets will normally be produced using the ipset -S command. I have this in my /etc/shorewall/stop file: if ipset -S > /etc/shorewall/ipsets.tmp; then mv -f /etc/shorewall/ipsets /etc/shorewall/ipsets.bak mv /etc/shorewall/ipsets.tmp /etc/shorewall/ipsets fi The above extension scripts will work most of the time but will fail in a shorewall stop - shorewall start sequence if you use ipsets in your routestopped file (see below). Your ipsets may not be reloaded until Shorewall is stopped or cleared. If you specify ipsets in your routestopped file then Shorewall must be cleared in order to reload your ipsets. As a consequence, scripts generated by the Perl-based compiler will ignore /etc/shorewall/ipsets and will issue a warning if you set SAVE_IPSETS=Yes in shorewall.conf.
Beginning with Shorewall 4.4.6 (and 4.5.3), SAVE_IPSETS=Yes is once again supported. See shorewall.conf(5).
Because the configuration files (with the exception of /etc/shorewall/params) are now processed by the Shorewall-perl compiler rather than by the shell, only the basic forms of Shell expansion ($variable and ${variable}) are supported. The more exotic forms such as ${variable:=default} are not supported. Both variables defined in /etc/shorewall/params and environmental variables (exported by the shell) can be used in configuration files. USE_ACTIONS=No is not supported. That option is intended to minimize Shorewall's footprint in embedded applications. As a consequence, Default Macros are not supported by Shorewall-perl. DELAYBLACKLISTLOAD=Yes is not supported. The entire rule set is atomically loaded with one execution of iptables-restore. MAPOLDACTIONS=Yes is not supported. People should have converted to using macros by now. The pre Shorewall-3.0 format of the zones file is not supported (IPSECFILE=ipsec); neither is the /etc/shorewall/ipsec file. BLACKLISTNEWONLY=No is not permitted with FASTACCEPT=Yes. This combination doesn't work in previous versions of Shorewall so the Perl-based compiler simply rejects it. Shorewall-perl has a single rule generator that is used for all rule-oriented files. This implementation enforces consistency of syntax between files. With shorewall-shell, there is a special syntax in the SOURCE column of /etc/shorewall/masq to designate "all traffic entering the firewall on this interface except...". Example:#INTERFACE SOURCE ADDRESSES eth0 eth1!192.168.4.9 ...Shorewall-perl uses syntax that is consistent with the rest of Shorewall:#INTERFACE SOURCE ADDRESSES eth0 eth1:!192.168.4.9 ... The 'allowoutUPnP' built-in action is no longer supported. In kernel 2.6.14, the Netfilter team have removed support for '-m owner --owner-cmd' which that action depended on. The PKTTYPE option is ignored by Shorewall-perl. Shorewall-perl will use Address type match if it is available; otherwise, it will behave as if PKTTYPE=No had been specified. Shorewall-perl detects dead policy file entries that result when an entry is masked by an earlier more general entry. Example: #SOURCE DEST POLICY LOG LEVEL all all REJECT info loc net ACCEPT Shorewall-shell silently accepts the above even though the loc->net policy is useless. Shorewall-perl generates a fatal compilation error. In the SOURCE column of the rules file, when an interface name is followed by a list of IP addresses, the behavior of Shorewall-perl differs from that of Shorewall-shell. Example:#ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT loc:eth0:192.168.1.3,192.168.1.5 $FW tcp 22With Shorewall-shell, this rule accepts SSH connection to the firewall from 192.168.1.3 through eth0 or from 192.168.1.5 through any interface. With Shorewall-perl, the rule accepts SSH connections through eth0 from 192.168.1.3 and through eth0 from 192.168.1.5. Shorewall-shell supports this syntax that gives the same result as Shorewall-perl.#ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT loc:eth0:192.168.1.3,eth0:192.168.1.5 $fw tcp 22 Shorewall-perl does not support this alternative syntax. Shorewall-perl gives a warning if a zone name is entered in the DEST column of a nonat rule. Nonat rules include: DNAT- REDIRECT- NONAT So rather than this:#ACTION SOURCE DEST PROTO DEST PORT(S) DNAT- net loc:192.168.1.3 tcp 21 you instead want:#ACTION SOURCE DEST PROTO DEST PORT(S) DNAT- net 192.168.1.3 tcp 21 Supplying an interface name in the SOURCE column of /etc/shorewall/masq is deprecated as of Shorewall 4.4. 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 network() in CIDR format (e.g., 192.168.144.0/24).
Dependence on Perl Shorewall-perl is dependent on Perl which has a large disk footprint. This makes Shorewall-perl less desirable in an embedded environment. The best way to work around this limitation is to install Shorewall-perl on an administrative system and employ Shorewall-lite on your embedded systems. Shorewall-perl will run on Windows under Cygwin and on an Apple MacIntosh running OS X. Install from a shell prompt using the install.sh script.
Installing Shorewall Version 4.0 or 4.2 Shorewall 4.2 contains six packages, four of which are also included in Shorewall 4.0: Shorewall-shell - the old shell-based compiler and related components. Shorewall-perl - the new Perl-based compiler. Shorewall-common - the part of Shorewall common to both compilers. Shorewall-lite- same as the 3.4 version of Shorewall Lite. Can run scripts generated by either Shorewall-perl or Shorewall-shell. Shorewall6 - The utilities for creating and operating an Ipv6 firewall. Requires Shorewall-perl and Shorewall-common. Introduced in Shorewall 4.2.4. Shorewall6-lite - Ipv6 equivalent of Shorewall Lite. Can run scripts generated by Shoreall-perl 4.2.4 and later. If you upgrade to Shorewall Version 4.0 or 4.2, you must install Shorewall-shell and/or Shorewall-perl; in fact, if you are using the tarball for your installation, you must install Shorewall-shell and/or Shorewall-perl before you upgrade Shorewall. See the upgrade issues for details.
Compiler Selection (Shorewall 4.0-4.2) If you only install one compiler, then that compiler will be used. If you install both compilers, then the compiler actually used for IPv4 depends on the SHOREWALL_COMPILER setting in shorewall.conf. The value of this new option can be either 'perl' or 'shell'. If you add 'SHOREWALL_COMPILER=perl' to /etc/shorewall/shorewall.conf then by default, the new compiler will be used on the system. If you add it to shorewall.conf in a separate directory (such as a Shorewall-lite export directory) then the new compiler will only be used when you compile from that directory. If you only install one compiler, it is suggested that you do not set SHOREWALL_COMPILER. If both compilers are installed, you can select the compiler to use on the command line using the 'C option: '-C shell' means use the shell compiler '-C perl' means use the perl compiler The -C option overrides the setting in shorewall.conf. Example:shorewall restart -C perl When the Shorewall-perl compiler has been selected, the params file is processed using the shell option which causes all variables set within the file to be exported automatically by the shell. The Shorewall-perl compiler uses the current environmental variables to perform variable expansion within the other Shorewall configuration files.
The Shorewall Perl Modules In Shorewall 4.4 and later, Shorewall's Perl modules are installed by default in /usr/share/shorewall/Shorewall and the names of the packages are of the form Shorewall::name. So by using this directiveuse lib '/usr/share/shorewall'; You can then load the modules via normal Perl use statements.
/usr/share/shorewall/compiler.pl While the compiler is normally run indirectly using /sbin/shorewall, it can be run directly as well.compiler.pl [ option ... ] [ filename ] If a filename is given, then the configuration will be compiled and the output placed in the named file. If filename is not given, then the configuration will simply be syntax checked. Options are: -v<verbosity> --verbosity=<verbosity> The <verbosity> is a number between 0 and 2 and corresponds to the VERBOSITY setting in shorewall.conf. This setting controls the verbosity of the compiler itself. The VERBOSITY setting in the shorewall.conf file read by the compiler will determine the default verbosity for the compiled program. -e --export If given, the configuration will be compiled for export to another system. -d <directory> --directory=<directory> If this option is omitted, the configuration in /etc/shorewall is compiled/checked. Otherwise, the configuration in the named directory will be compiled/checked. -t --timestamp If given, each progress message issued by the compiler and by the compiled program will be timestamped. --debug If given, when a warning or error message is issued, it is supplemented with a stack trace. Requires the Carp Perl module. --refresh=<chainlist> If given, the compiled script's 'refresh' command will refresh the chains in the comma-separated <chainlist> rather than 'blacklst'. --log=<logfile> If given, compiler will log to this file provider that --log_verbosity is > -1. --log_verbosity=-1|0|1|2 If given, controls the verbosity of logging to the log specified by the --log parameter. -f=4|6 --family=4|6 Specifies whether an IPv4 or an IPv6 firewall is to be created. --preview Added in Shorewall 4.4.6. If no filename is given, this option causes the generated input to iptables-input to be displayed on standard output. -c --confess Added in Shorewall 4.4.20. Causes error and warning messages to include a Perl stack trace. Useful for finding the place in the code where the message is generated. -u --update Added in Shorewall 4.4.21. Causes the .conf file to be updated (shorewall update command). -a --annotate Added in Shorewall 4.4.21. Causes the updated .conf file to be annotated with documentation. Ignored unless --update is also specified. --convert Added in Shorewall 4.4.26. Causes the compiler to convert an existing blacklist file into an equivalent blrules file. --config_path=path[:path]... Added in Shorewall 4.4.26. Search path for configuration files. --shorewallrc=path Added in Shorewall 4.5.1. Specifies the location of the shorewallrc file. Example (compiles the configuration in the current directory generating a script named 'firewall' and using VERBOSITY 2)./usr/share/shorewall/compiler.pl -v 2 -d . firewall Prior to Shorewall 4.4.19, the Perl-based compiler did not process /etc/shorewall/params. To include definitions in that file, you would need to do something like the following:. /usr/share/shorewall/lib.base # In case /etc/shorewall/params does INCLUDE set -a # Export all variables set in /etc/shorewall/params . /etc/shorewall/params set +a /usr/share/compiler.pl ...
Shorewall::Compiler To avoid a proliferation of parameters to Shorewall::Compiler::compile(), that function uses named parameters. Parameter names are: script ('object' is also accepted but deprecated) Output script file. If omitted or '', the configuration is syntax checked. directory Directory. If omitted or '', configuration files are located using CONFIG_PATH. Otherwise, the directory named by this parameter is searched first. verbosity Verbosity; range -1 to 2 timestamp 0|1 -- timestamp messages. debug 0|1 -- include stack trace in warning/error messages. export 0|1 -- compile for export. chains List of chains to be reloaded by 'refresh' log File to log compiler messages to. log_verbosity Log Verbosity; range -1 to 2. family Address family: 4 or 6 preview 0 or 1. Added in Shorewall 4.4.6. A value of 1 causes the generated ruleset to be printed to standard output. confess 0 or 1. Added in Shorewall 4.4.20. A value of 1 causes error and warning messages to include a Perl stack trace. Useful for finding the place in the code where the message is generated. update 0 or 1. Added in Shorewall 4.4.21. A value of 1 causes the .conf file to be updated (shorewall update command). config_path List of pathnames separated by ':' or ''. Added in Shorewall 4.4.26. The list of directories where the compiler is to search for input files. shorewallrc Pathname of the global shorewallrc file. Added in Shorewall 4.5.1. shorewallrc1 Pathname of the export shorewallrc file. Added in Shorewall 4.5.8. Those parameters that are supplied must have defined values. Defaults are: script: '' ('check' command) directory: '' verbosity: 1 timestamp: 0 debug: 0 export: 0 chains: '' log: '' log_verbosity: -1 family: 4 preview: 0 confess: 0 update: 0 config_path: Contents of /var/lib/shorewall/configpath or /var/lib/shorewall6/configpath depending on the setting of family. shorewallrc: ''. Example: use lib '/usr/share/shorewall/'; use Shorewall::Compiler; compiler( script => '/root/firewall', log => '/root/compile.log', log_verbosity => 2 );
Shorewall::Chains use lib '/usr/share/shorewall'; use Shorewall::Chains; my $chainref1 = chain_new $table, $name1; add_rule $chainref1, $rule; insert_rule $chainref1, $ordinal, $rule; my $chainref2 = new_manual_chain $name3; my $chainref3 = ensure_manual_chain $name; log_rule_limit $level, $chainref3, $name, $disposition, $limit, $tag, $command, $predicates; my $chainref4 = $chain_table{$table}{$name}; my $chainref5 = $nat_table{$name}; my $chainref6 = $mangle_table{$name}; my $chainref7 = $filter_table{$name};Shorewall::Chains is Shorewall-perl's interface to iptables/netfilter. It creates a chain table (%chain_table) which is populated as the various tables are processed. The table (actually a hash) is two-dimensional with the first dimension being the Netfilter table name (raw, mangle, nat and filter) and the second dimension being the chain name. Each table is a hash reference -- the hash defines the attributes of the chain. See the large comment at the beginning of the module (/usr/share/shorewall-perl/Shorewall/Chains.pm). The module export the chain table along with three hash references into the table: $nat_table Reference to the 'nat' portion of the table ($chain_table{nat}). This is a hash whose key is the chain name. This variable is not set when an IPv6 firewall is being created. $mangle_table Reference to the 'mangle' portion of the table ($chain_table{mangle}). This is a hash whose key is the chain name. $filter Reference to the 'filter' portion of the table ($chain_table{filter}). This is a hash whose key is the chain name. You can create a new chain in any of the tables using new_chain(). Arguments to the function are: $table 'nat', 'mangle', or 'filter'. $name Name of the chain to create. The function creates a hash at $chain_table{$table}{$name} and populates the hash with default values. A reference to the hash is returned. Each chain table entry includes a list of rules to be added to the chain. These rules are written to the iptables-restore input file when the resulting script is executed. To append a rule to that list, call add_rule(). Arguments are: $chainref A reference to the chain table entry. $rule The rule to add. Do not include the leading '-A ' in this argument -- it will be supplied by the function. To insert a rule into that list, call insert_rule(). Arguments are: $chainref A reference to the chain table entry. $ordinal The position of the inserted rule in the list. A value of 1 inserts the rule at the head of the list, a value of 2 places the rule second in the list, and so on. $rule The rule to add. Do not include the leading '-I' in this argument -- it will be supplied by the function. To create a manual chain, use the new_manual_chain() function. The function accepts a single argument which is the name of the chain. The function returns a reference to the resulting chain table entry. A companion function, ensure_manual_chain(), can be called when a manual chain of the desired name may have already been created. If a manual chain table entry with the passed name already exists, a reference to the chain table entry is returned. Otherwise, the function calls new_manual_chain() and returns the result. To create a logging rule, call log_rule_limit(). Arguments are: $level The log level. May be specified as a name or as a number. $chainref Chain table reference for the chain to which the rule is to be added. $name The chain name to be reported in the log message (see LOGFORMAT in shorewall.conf(5)). $disposition The disposition to be reported in the log message (see LOGFORMAT in shorewall.conf(5)). $limit Rate limiting match. If an empty string is passed, the LOGRATE/LOGBURST (shorewall.conf(5)) is used. $tag Log tag. $command If 'add', append the log rule to the chain. If 'insert', then insert the rule at the beginning of the chain. $predicates Any additional matches that are to be applied to the rule.
Shorewall::Config use lib '/usr/share/shorewall'; use Shorewall::Config; warning message "This entry is bogus"; fatal_error "You have made an error"; progress_message "This will only be seen if VERBOSITY >= 2"; progress_message2 "This will only be seen if VERBOSITY >= 1"; progress_message3 "This will be seen unless VERBOSITY < 0"; The shorewall() function may be optionally included:use lib '/usr/share/shorewall'; use Shorewall::Config qw/shorewall/; shorewall $config_file_entry;The Shorewall::Config module provides basic services to Shorewall-perl. By default, it exports the functions that produce progress messages and warning/error messages. To issue a warning message, call warning_message(). The single argument describes the warning. To raise a fatal error, call fatal_error(). Again, the single argument described the error. In both cases, the function will augment the warning/error with the current configuration file and line number, if any. fatal_error() raised an exception via either confess() or die(), depending on whether the debugging stack trace is enabled or not.. The three 'progress message' functions conditionally produce output depending on the current verbosity setting. The shorewall() function is used by embedded Perl scripts to generate entries to be included in the current configuration file.
shorewall-docs-xml-4.5.21/MultiISP_ru.xml0000644000175000017500000015162412222401136020123 0ustar teastepteastep
Shorewall и подключение к Internet по нескольким каналам Tom Eastep 2005 2006 2007 Thomas M. Eastep 2007 Russian Translation: Grigory Mokhin Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии 1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке GNU Free Documentation License. Вы должны установить современный дистрибутив, который обновляется поставщиком, прежде чем пытаться настроить работу в этом режиме. Старые дистрибутивы не удовлетворяют минимальным требованиям, и вам потребуется перекомпилировать iptables, ядро и прочее программное обеспечение в системе. Если вы проигнорируете этот совет, то не рассчитывайте, что кто-либо сможет вам помочь.. Чтение только документации Shorewall не будет достаточным для понимания раскрываемых здесь тем. Shorewall упрощает работу с iptables, но разработчики Shorewall не имеют достаточных ресурсов, чтобы учить вас основам управляемой маршрутизации в Linux (равно как и пособие по вождению комбайна не учит правильно выращивать пшеницу). Скорее всего вам потребуется обратиться к следующим дополнительным источникам: LARTC HOWTO: http://www.lartc.org Вывод команды man ip Вывод команд ip route help и ip rule help
Поддержка нескольких соединений с Internet Начиная с версии 2.3.2 в Shorewall реализована ограниченная поддержка нескольких соединений с Internet. Ниже описаны существующие ограничения: Используется статическая конфигурация маршрутов. Поэтому не предусмотрены меры по защите от сбоя какого-либо из каналов связи с провайдером. Изменения маршрутизации и очистка кэша маршрутов осуществляются при запуске и при перезапуске Shorewall (если не указана опция "-n" для shorewall restart). Вообще говоря, в идеальном случае перезапуск пакетного фильтра никак не должен влиять на маршрутизацию. В версиях Shorewall ниже 3.4.0 маршруты и правила маршрутизации, добавляемые при запуске, не удалялись полностью в ходе выполнения команд shorewall stop, shorewall clear или shorewall restart.
Обзор Предположим, что система, в которой работает файрвол, подключена к двум провайдерам по двум интерфейсам Ethernet, как показано на рисунке. eth0 подключен к ISP1. IP-адрес eth0 - это 206.124.146.176, и шлюз провайдера имеет IP-адрес 206.124.146.254. eth1 подключен к ISP2. IP-адрес eth1 - это 130.252.99.27, и шлюз провайдера имеет IP-адрес 130.252.99.254. eth2 подключен к локальной сети. У него может быть любой IP-адрес. Все эти провайдеры должны быть перечислены в файле /etc/shorewall/providers. В записях в файле /etc/shorewall/providers можно указать, что для исходящих соединений должно быть включено распределение нагрузки по двум каналам связи с провайдерами. В записях в файле /etc/shorewall/tcrules можно указать, что некоторые исходящие соединения должны использовать определённый канал провайдера. Правила в файле /etc/shorewall/tcrules необязательны для того, чтобы настройка /etc/shorewall/providers работала, но необходимо указать уникальное значение MARK для каждого из провайдеров, чтобы Shorewall настроил правила маркировки. Если задать опцию track в файле /etc/shorewall/providers, то соединения из Internet будут автоматически маршрутизироваться обратно через правильный интерфейс на соответствующий шлюз провайдера. Это будет работать как в том случае, когда соединение обрабатывается самим файрволом, так и для соединений, маршрутизируемых или пробрасываемых к системам позади файрвола. Shorewall настраивает маршрутизацию и обновляет файл /etc/iproute2/rt_tables, включая в него имена таблиц и их номера. При этом используются функции маркировки пакетов для управления маршрутизацией. Как следствие этого возникают ограничения на записи в файле /etc/shorewall/tcrules: Маркировка пакетов для целей управления трафиком не может осуществляться в цепочке PREROUTING для соединений с участием провайдеров, для которых задана опция 'track' (см. далее). Нельзя использовать опции SAVE или RESTORE. Нельзя использовать маркировку соединений. Файл /etc/shorewall/providers может также использоваться в других сценариях маршрутизации. В документации по работе с Squid приведены примеры.
Файл /etc/shorewall/providers Далее описаны поля этого файла. Как и везде в файлах конфигурации Shorewall, укажите в поле для столбца "-", если не требуется задавать никакое значение. NAME Имя провайдера. Должно начинаться с буквы и состоять из букв и цифр. Имя провайдера становится именем сгенерированной таблицы маршрутизации для этого провайдера. NUMBER Число от 1 до 252. Оно будет номером таблицы маршрутизации для сгенерированной таблицы для этого провайдера. MARK Метка, применяемая в файле /etc/shorewall/tcrules для направления пакетов через этого провайдера. Shorewall также помечает этой меткой соединения, которые входят через этого провайдера, и восстанавливает метку пакета в цепочке PREROUTING. Метка должна быть целым числом от 1 до 255. Начиная с Shorewall версии 3.2.0 Beta 6, можно задать опцию HIGH_ROUTE_MARKS=Yes в файле /etc/shorewall/shorewall.conf. Это позволяет решить следующие задачи: Использовать метки пакетов для управления трафиком, при условии что эти метки присваиваются в цепочке FORWARD. Использовать значения меток > 255 для меток провайдера. Эти метки должны быть кратными 256 в диапазоне 256-65280 (в 16-ричном представлении 0x100 - 0xFF00, с нулевыми младшими 8 битами). DUPLICATE Имя или номер таблицы маршрутизации, которая будет продублирована. Можно указать 'main' или имя или номер ранее объявленного провайдера. Для большинства приложений здесь достаточно будет указать 'main'. INTERFACE Имя интерфейса канала связи с провайдером. В реализации поддержки нескольких подключений с провайдерами Shorewall предполагается, что каждый провайдер подключен к собственному интерфейсу. GATEWAY IP-адрес шлюза провайдера. Здесь можно указать detect для автоматического определения IP-адреса шлюза. Совет: "detect" следует указывать в том случае, если интерфейс из поля INTERFACE настраивается динамически по DHCP. OPTIONS Список параметров через запятую, описанных ниже: track Если эта опция включена, то будут отслеживаться соединения, ВХОДЯЩИЕ через этот интерфейс, чтобы ответы могли маршрутизироваться обратно через этот же интерфейс. Укажите 'track', если через этого провайдера к локальным серверам будут обращаться хосты из Internet. Вместе с 'track' всегда следует указывать опцию 'balance'. Для работы с этой функцией ядро и iptables должны поддерживать цель CONNMARK и сравнение connmark. Расширение цели ROUTE не требуется. В iptables 1.3.1 есть ошибка в реализации CONNMARK и iptables-save/iptables-restore. Поэтому при настройке нескольких провайдеров команда shorewall restore может быть не выполнена. Если это имеет место, примените исправление iptables, доступное по адресу http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff. Если используется файл /etc/shorewall/providers для настройки нескольких соединений с Internet, укажите опцию 'track', даже если в ней нет необходимости. Она помогает поддерживать длительные соединения, в которых могут быть долгие периоды отсутствия трафика. balance Опция 'balance' позволяет распределять нагрузку исходящих потоков между несколькими провайдерами. Распределение нагрузки не будет идеальным, поскольку оно осуществляется посредством маршрутов, а маршруты кэшируются. При этом маршрут к хостам, к которым часто обращаются пользователи, будет проходить всегда через одного и того же провайдера. По умолчанию всем провайдерам присваивается одинаковый вес (1). Вес конкретного провайдера можно изменить опцией balance с "=" и весом (например, balance=2). Веса отражают относительную пропускную способность каналов связи с провайдером. Они должны быть небольшими числами, потому что ядро создает дополнительные маршруты для каждого приращения веса. Если файл /etc/shorewall/providers используется для настройки нескольких соединений с Internet, укажите опцию 'balance', даже если в ней нет необходимости. Для направления всего трафика через какого-либо определенного провайдера можно использовать файл /etc/shorewall/tcrules. Если вы проигнорируете этот совет, то прочитайте FAQ 57 и FAQ 58. Если указана опция 'balance', но весь трафик по-прежнему идёт через одного провайдера, то причина этого может состоять в том, что ядро не собрано с опцией CONFIG_IP_ROUTE_MULTIPATH_CACHED=n. У некоторых пользователей пересборка ядра с этой опцией помогла устранить неполадку. Эта неполадка присутствует в ядре SuSE 10.0, и согласно в этом случае может возникать критическая ошибка ядра. В SUSE 10.1 и SLES 10 опция CONFIG_IP_ROUTE_MULTIPATH_CACHED=n включена по умолчанию. Источник неполадки описан здесь: несовместимость между исправлениями от LARTC и опцией CONFIG_IP_ROUTE_MULTIPATH_CACHED. loose Не включать правила маршрутизации, которые принудительно направляют через данный интерфейс трафик, исходный IP-адрес которого совпадает с адресом интерфейса канала с провайдером. Эта опция полезна для определения провайдеров, которые должны использоваться только при наличии соответствующей метки пакета. Эту опцию нельзя указывать совместно с balance. optional (начиная с Shorewall 3.2.2) Shorewall определит, работает ли этот интерфейс и настроен ли его IP-адрес. Если он не настроен, то будет показано предупреждение, а сам провайдер не будет включен. Параметр 'optional' предназначен для определения состояния интерфейсов, которые могли бы вызвать сбой команды shorewall start или shorewall restart - однако даже если интерфейс находится в состоянии, в котором Shorewall может [пере]запуститься без ошибок, это не означает, что трафик может с гарантией проходить через этот интерфейс. Для тех, кто окончательно запутался в том, что такое track и balance: track управляет входящими соединениями. balance управляет исходящими соединениями. COPY Если в поле DUPLICATE указана существующая таблица, то Shorewall копирует все маршруты, проходящие через интерфейс, указанный в столбце INTERFACE, а также через интерфейс, указанный в этом поле. В этом поле следует указать все интерфейсы в системе файрвола, исключая интерфейсы Internet, указанные в поле INTERFACE этого файла.
Какие функции выполняет запись в файле providers Добавление записи в файле providers приводит к созданию альтернативной таблицы маршрутизации. Помимо этого: Если не указана опция loose, то создается правило ip для каждого IP-адреса из поля INTERFACE, которое обеспечивает маршрутизацию трафика с этого адреса через соответствующую таблицу маршрутизации. Если указана опция track, то соединения, для которых хотя бы один пакет прошел на интерфейс, указанный в поле INTERFACE, получат метку соединения, заданную в поле MARK. В цепочке PREROUTING метка пакетов, имеющих метку соединения, будет задана равной метке соединения, и такие помеченные пакеты не будут подчиняться правилам для цепочки PREROUTING, заданным в файле /etc/shorewall/tcrules. Это обеспечивает маршрутизацию через правильный интерфейс для входящих соединений. Если указана опция balance, то Shorewall заменит маршрут по умолчанию с весом 100 в таблице маршрутизации 'main' маршрутом с распределением нагрузки между шлюзами, для которых опция balance включена. Поэтому, если вы настраиваете маршруты по умолчанию, то укажите их вес меньше, чем 100, иначе маршрут, добавленный Shorewall, не будет иметь силы. Больше эти записи не делают ничего. Вспомните основной принцип, описанный в документации по маршрутизации Shorewall: Маршрутизация отвечает за то, куда направляются пакеты. После того, как маршрут пакета определён, файрвол (Shorewall) определяет, разрешить ли отправку пакета по его маршруту. Итак, если вы хотите направить трафик через определённого провайдера, то необходимо пометить этот трафик значением MARK провайдера в файле /etc/shorewall/tcrules и пометить пакет в цепочке PREROUTING; другим способом будет указание соответствующих правил в файле /etc/shorewall/rtrules. В Shorewall версий ниже 3.4.0 записи из файла /etc/shorewall/providers необратимо изменяют маршрутизацию системы, то есть эти изменения не отменяются при вызове команды shorewall stop или shorewall clear. Для того чтобы восстановить исходные маршруты, может потребоваться перезапустить сеть. Обычно это делает команда /etc/init.d/network restart или /etc/init.d/networking restart. Обратитесь к документации по сети вашего дистрибутива. Дополнительные замечания: Влияние изменений, вносимых Shorewall в таблицу маршрутизации, можно уменьшить, указав параметр metric для каждого настраиваемого маршрута по умолчанию. Shorewall создаст маршрут по умолчанию с распределением нагрузки (если опция balance включена для какого-либо из провайдеров), который не будет включать метрику и тем самым не будет заменять никакой существующий маршрут, для которого метрика отлична от нуля. Опция -n команд shorewall restart и shorewall restore позволяет предотвратить изменение маршрутизации. Файл /etc/shorewall/stopped можно также использовать для восстановления маршрутизации при остановке Shorewall. Когда система работает в обычной конфигурации маршрутизации (одна таблица), то ее содержимое можно сохранить следующим образом: ip route ls > routes Ниже приведен пример файла routes для моей системы: 192.168.1.1 dev eth3 scope link 206.124.146.177 dev eth1 scope link 192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1 192.168.2.0/24 via 192.168.2.2 dev tun0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254 206.124.146.0/24 dev eth3 proto kernel scope link src 206.124.146.176 169.254.0.0/16 dev eth0 scope link 127.0.0.0/8 dev lo scope link default via 206.124.146.254 dev eth3 Отредактируйте этот файл следующим образом: ip route flush table main ip route add 192.168.1.1 dev eth3 scope link ip route add 206.124.146.177 dev eth1 scope link 192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1 192.168.2.0/24 via 192.168.2.2 dev tun0 192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1 192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1 ip route add 206.124.146.177 dev eth1 scope link ip route add 206.124.146.177 dev eth1 scope link ip route add 206.124.146.177 dev eth1 scope link ip route flush cache Сохраните этот файл как /etc/shorewall/stopped. В этот файл можно также добавить следующее: ip rule ls | while read priority rule; do case ${priority%:} in 0|3276[67]) ;; *) ip rule del $rule ;; esac done Этот код удаляет все правила маршрутов, за исключением маршрута по умолчанию.
Какие функции НЕ выполняет запись в файле providers Shorewall - это инструмент для настройки Netfilter, а не процесс, который непрерывно работает в системе, поэтому записи в файле providers не обеспечивают автоматического переключения в случае сбоя одного из каналов связи с Internet .
Марсианские пакеты В конфигурации с несколькими провайдерами часто возникает типичная неполадка с "марсианскими пакетами". Если для сетевых интерфейсов задана опция routefilter в файле /etc/shorewall/interfaces (а вместе с этой опцией должны быть задана опция logmartians), то могут возникать ошибки, и в протоколе будут сообщения следующего вида: Feb 9 17:23:45 gw.ilinx kernel: martian source 206.124.146.176 from 64.86.88.116, on dev eth1 Feb 9 17:23:45 gw.ilinx kernel: ll header: 00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00 Это сообщение может ввести в заблуждение. Исходным IP входящего пакета является 64.86.88.116, а целевым IP - 206.124.146.176. Следует также учитывать, что целевой IP-адрес входящего пакета мог быть уже изменен, либо в DNAT, либо записью в файле /etc/shorewall/masq (SNAT или Masquerade) для первоначального исходящего соединения. Поэтому целевой IP-адрес (206.124.146.176) может отличаться от исходного целевого IP-адреса пришедшего пакета. Эти неполадки могут возникать по следующим причинам: Оба внешних интерфейса подключены на один хаб или коммутатор. Никогда не подключайте несколько интерфейсов файрвола на один хаб, если хотите избежать неприятных и труднообъяснимых неполадок. В файле providers указаны вместе опции loose и balance. Это приводит к тому, что отдельные соединения будут перескакивать между интерфейсами, и будут возникать ошибки. Локальный трафик направляется через один из интерфейсов с помощью маркировки пакетов записью из файла /etc/shorewall/tcrules. Вместо этого следует привязать приложение к соответствующему локальному IP-адресу требуемого интерфейса. См. далее. Если больше ничего не помогает, удалите опцию routefilter для внешнего интерфейса. При этом можно добавить правила для регистрации и сбрасывания пакетов из Интернета, имеющих адрес источника из вашей локальной сети. Например, если локальная сеть в указанной выше конфигурации имеет адреса 192.168.1.0/24, то добавьте следующее правило: #ACTION SOURCE DEST DROP:info net:192.168.1.0/24 all Be sure the above rule is added before any other rules with net in the SOURCE column.
Пример Конфигурация схемы сети, показанной на рисунке в начале этого документа, описывается в файле /etc/shorewall/providers следующим образом. #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY ISP1 1 1 main eth0 206.124.146.254 track,balance eth2 ISP2 2 2 main eth1 130.252.99.254 track,balance eth2 Прочие файлы конфигурации будут иметь следующий вид: /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect … net eth1 detect … /etc/shorewall/policy: #SOURCE DESTINATION POLICY LIMIT:BURST net net DROP Если соединения файрвола будут перенаправляться с помощью правил /etc/shorewall/tcrules, или если для провайдеров указана опция balance, то независимо от того, есть ли маскируемые хосты, в файл /etc/shorewall/masq необходимо добавить следующие записи. #INTERFACE SUBNET ADDRESS eth0 130.252.99.27 206.124.146.176 eth1 206.124.146.176 130.252.99.27 Эти записи обеспечивают отправку пакетов, созданных в системе файрвола, с правильным исходным IP-адресом, соответствующим интерфейсу, через который они направляются. Если какой-либо из интерфейсов имеет динамический IP-адрес, то указанные правила можно создать с помощью переменных оболочки. Например, если eth0 имеет динамический IP-адрес: /etc/shorewall/params: ETH0_IP=$(find_first_interface_address eth0) /etc/shorewall/masq: #INTERFACE SUBNET ADDRESS eth0 130.252.99.27 $ETH0_IP eth1 $ETH0_IP 130.252.99.27 Если есть маскируемые хосты, то настройте в файле /etc/shorewall/masq маскарадинг для обоих провайдеров. Например, если маскируются хосты, подключенные через eth2 то это делается так: #INTERFACE SUBNET ADDRESS eth0 eth2 206.124.146.176 eth1 eth2 130.252.99.27 Записи в файле /etc/shorewall/masq никак не влияют на то, через какого провайдера пройдёт конкретное соединение. Для этого применяются правила в файле /etc/shorewall/tcrules или /etc/shorewall/rtrules. Предположим, что требуется направить весь исходящий трафик SMTP из локальной сети через провайдера 2. В файле /etc/shorewall/tcrules укажите следующее (и в версии Shorewall ниже 3.0.0 также задайте TC_ENABLED=Yes в файле /etc/shorewall/shorewall.conf). #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST # PORT(S) 2:P <локальная сеть> 0.0.0.0/0 tcp 25
Если провайдеров больше, чем 2 Для более чем двух провайдеров требуется внести соответствующие дополнения: Для каждого внешнего адреса в файл /etc/shorewall/masq необходимо добавить записи для случаев, когда соединение, использующее этот адрес как SOURCE, направляется через интерфейс с отличным адресом. Для каждого внешнего интерфейса в файл /etc/shorewall/masq необходимо добавить записи для каждой внутренней подсети, которая будет маскироваться (или для которой применяется SNAT) через этот интерфейс. Например, для eth3 с IP-адресом 16.105.78.4 и шлюзом 16.105.78.254, необходимо добавить следующее: /etc/shorewall/providers:#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY ISP1 1 1 main eth0 206.124.146.254 track,balance eth2 ISP2 2 2 main eth1 130.252.99.254 track,balance eth2 ISP3 3 3 main eth3 16.105.78.254 track,balance eth2 /etc/shorewall/masq:#INTERFACE SUBNET ADDRESS eth0 130.252.99.27 206.124.146.176 eth3 130.252.99.27 16.105.78.4 eth1 206.124.146.176 130.252.99.27 eth3 206.124.146.176 16.105.78.4 eth0 16.106.78.4 206.124.146.176 eth1 16.106.78.4 130.252.99.27 eth0 eth2 206.124.146.176 eth1 eth2 130.252.99.27 eth3 eth2 16.105.78.4
Приложения, работающие в системе файрвола Иногда возникают неполадки с приложениями, работающими в системе файрвола. Это часто имеет место, для для внешних интерфейсов в файле /etc/shorewall/interfaces указана опция routefilter (см. выше). В этом случае рекомендуется связать приложение с определенным локальным IP-адресом вместо 0. Примеры: Squid: В файле squid.conf задайте tcp_outgoing_address равным IP-адресу интерфейса, на котором будет работать Squid. Для OpenVPN задайте опцию local(--local в командной строке с IP-адресом, на котором должен принимать соединения сервер.
/etc/shorewall/rtrules Файл /etc/shorewall/rtrules добавлен в Shorewall в версии 3.2.0. Файл rtrules позволяет направлять определенный трафик через конкретного провайдера, как и записи из файла tcrules . Разница между этими двумя файлами состоит в том что записи в rtrules никак не связаны с Netfilter. В Shorewall версий ниже 3.4.0 записи из файла /etc/shorewall/rtrules необратимо изменяют маршрутизацию в системе, то есть эти изменения не отменяются при вызове команды shorewall stop или shorewall clear. Для того чтобы восстановить исходные маршруты, может потребоваться перезапустить сеть. Обычно это делает команда /etc/init.d/network restart или /etc/init.d/networking restart. Обратитесь к документации по сети вашего дистрибутива. Также обратите внимание на предупреждение в разделе Какие функции выполняет запись в файле providers.
Правила маршрутизации Правила маршрутизации управляются ядром Linux. Их можно просмотреть командой ip rule ls . При маршрутизации пакета правила обрабатываются в указанном порядке, пока не будет найден маршрут пакета. gateway:~ # ip rule ls 0: from all lookup local <=== Локальные IP-адреса (система файрвола) 10001: from all fwmark 0x1 lookup Blarg <=== Это и следующее правило генерируются 10002: from all fwmark 0x2 lookup Comcast записями 'MARK' из /etc/shorewall/providers. 20000: from 206.124.146.176 lookup Blarg <=== Это и следующее правило не генерируются, если 20256: from 24.12.22.33 lookup Comcast указана опция 'loose'; они основаны на выводе 'ip addr ls' 32766: from all lookup main <=== Это таблица маршрутизации, показанная в выводе 'iproute -n' 32767: from all lookup default <=== Эта таблица обычно пуста gateway:~ # В этом примере настроены два провайдера: Blarg и Comcast, с метками MARK 1 и 2 соответственно.
Файл rtrules Далее описаны столбцы файла: SOURCE (Необязательный) IP-адрес (подсеть или хост), с которыми совпадает исходный IP-адрес пакета. Может указываться как имя интерфейса, за которым следует необязательная часть из ":" и адреса. Если указано устройство 'lo', то пакет должен исходить из системы файрвола. DEST (Необязательный) IP-адрес (подсеть или хост), с которыми совпадает целевой IP-адрес пакета. Если опущен SOURCE или DEST, то в укажите в одном из этих полей "-". Необходимо задать хотя бы одно из полей SOURCE или DEST. PROVIDER Провайдер, через которого должен проходить трафик. Может быть задан как имя провайдера или его номер. PRIORITY Приоритет правила, определяющий порядок обработки правил. 1000-1999: перед правилами Shorewall, генерируемыми на основе меток 'MARK' 11000- 11999: после правил 'MARK', но перед правилами Shorewall, генерируемыми для интерфейсов провайдеров. 26000-26999: после интерфейсов провайдеров, но перед правилом 'default'. Правила с одинаковым приоритетом обрабатываются в том порядке, как они указаны в файле. Пример 1: Направить весь трафик, приходящий на eth1, через Comcast. #SOURCE DEST PROVIDER PRIORITY eth1 - Comcast 1000 С этим правилом вывод ip rule ls будет следующим. gateway:~ # ip rule ls 0: from all lookup local 1000: from all iif eth1 lookup Comcast 10001: from all fwmark 0x1 lookup Blarg 10002: from all fwmark 0x2 lookup Comcast 20000: from 206.124.146.176 lookup Blarg 20256: from 24.12.22.33 lookup Comcast 32766: from all lookup main 32767: from all lookup default gateway:~ #Обратите внимание, что приоритет 1000 приводит к тому, что проверка на eth1 осуществляется перед проверкой fwmark. Пример 2: Используется OpenVPN (маршрутизируемая конфигурация /tunX) в сочетании с несколькими провайдерами. В этом случае необходимо настроить правило, согласно которому трафик OpenVPN будет направляться обратно через интерфейс tunX, а не через какого-либо из провайдеров. 10.8.0.0/24 - это подсеть, выбранная для OpenVPN (сервер 10.8.0.0 255.255.255.0). #SOURCE DEST PROVIDER PRIORITY - 10.8.0.0/24 main 1000
shorewall-docs-xml-4.5.21/IPIP.xml0000644000175000017500000001377012222401136016507 0ustar teastepteastep
GRE and IPIP Tunnels Tom Eastep 2001 2002 2003 2004 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. GRE and IPIP Tunnels are insecure when used over the Internet; use them at your own risk GRE and IPIP tunneling with Shorewall can be used to bridge two masqueraded networks. The simple scripts described in the Linux Advanced Routing and Shaping HOWTO work fine with Shorewall. Shorewall also includes a tunnel script for automating tunnel configuration. If you have installed the RPM, the tunnel script may be found in the Shorewall documentation directory (usually /usr/share/doc/shorewall-<version>/).
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. The tunnel script is not installed in /etc/shorewall by default -- If you install using the tarball, the script is included in the tarball; if you install using the RPM, the file is in your Shorewall documentation directory (normally /usr/share/doc/shorewall-<version>). In the /etc/shorewall/tunnel script, set the tunnel_type parameter to the type of tunnel that you want to create. /etc/shorewall/tunnel tunnel_type=gre If you use the PPTP connection tracking modules from Netfilter Patch-O-Matic (ip_conntrack_proto_gre ip_conntrack_pptp, ip_nat_proto_gre and ip_nat_pptp) then you cannot use GRE tunnels. 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 tosysb 10.255.255.255 In /etc/shorewall/tunnels on system A, we need the following: #TYPE ZONE GATEWAY GATEWAY ZONE ipip net 134.28.54.2 This entry in /etc/shorewall/tunnels, opens the firewall so that the IP encapsulation protocol (4) will be accepted to/from the remote gateway. In the tunnel script on system A: tunnel script on system A tunnel=tosysb myrealip=206.161.148.9 (for GRE tunnel only) myip=192.168.1.1 hisip=10.0.0.1 gateway=134.28.54.2 subnet=10.0.0.0/8 Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn zone. In /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST vpn tosysa 192.168.1.255 In /etc/shorewall/tunnels on system B, we have: #TYPE ZONE GATEWAY GATEWAY ZONE ipip net 206.191.148.9 And in the tunnel script on system B: tunnel script on system B tunnel=tosysa myrealip=134.28.54.2 (for GRE tunnel only) myip=10.0.0.1 hisip=192.168.1.1 gateway=206.191.148.9 subnet=192.168.1.0/24 You can rename the modified tunnel scripts if you like; be sure that they are secured so that root can execute them. 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 run the modified tunnel script with the start argument on each system. The systems in the two masqueraded subnetworks can now talk to each other
shorewall-docs-xml-4.5.21/Manpages.xml0000644000175000017500000002124212222401136017472 0ustar teastepteastep
Shorewall 4.4 Manpages Tom Eastep 2007 2008 2009 2010 2011 2012 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. These manpages are for Shorewall 4.0 only. They describe features and options not available on earlier releases. The docbook to manpage translation tool that we are using has some indentation issues which require us to choose between correct output of the man command and correctly-indented HTML. We've chosen in favor of the man command so some of the manpages accessed through the links below have indentation problems. We're working to resolve these issues and ask for your patience.
Section 5 — Files and Concepts
accounting - Define IP accounting rules. actions - Declare user-defined actions. arprules - (Added in Shorewall 4.5.12) Define arpfilter rules. blacklist - Static blacklisting. conntrack - Specify helpers for connections or exempt certain traffic from netfilter connection tracking. ecn - Disabling Explicit Congestion Notification exclusion - Excluding hosts from a network or zone hosts - Define multiple zones accessed through a single interface interfaces - Define the interfaces on the system and optionally associate them with zones. ipsets - Describes how to specify set names in Shorewall configuration files. maclist - Define MAC verification. masq - Define Masquerade/SNAT modules - Specify which kernel modules to load. nat - Define one-to-one NAT. nesting - How to define nested zones. netmap - How to map addresses from one net to another. notrack - Exclude certain traffic from Netfilter connection tracking params - Assign values to shell variables used in other files. policy - Define high-level policies for connections between zones. providers - Define routing tables, usually for multiple Internet links. proxyarp - Define Proxy ARP. rtrules - Define routing rules. routes - (Added in Shorewall 4.4.15) Add additional routes to provider routing tables. routestopped - Specify connections to be permitted when Shorewall is in the stopped state (deprecated in Shorewall 4.5.8). rules - Specify exceptions to policies, including DNAT and REDIRECT. secmarks - Attach an SELinux context to a packet. tcclasses - Define htb classes for traffic shaping. tcdevices - Specify speed of devices for traffic shaping. tcfilters - Classify traffic for shaping; often used with an IFB to shape ingress traffic. tcinterfaces - Specify devices for simplified traffic shaping. tcpri - Classify traffic for simplified traffic shaping. stoppedrules - Specify connections to be permitted when Shorewall is in the stopped state (added in Shorewall 4.5.8). tcrules - Define packet marking rules, usually for traffic shaping. tos - Define TOS field manipulation. tunnels - Define VPN connections with endpoints on the firewall. shorewall.conf - Specify values for global Shorewall options. shorewall-lite.conf - Specify values for global Shorewall Lite options. vardir - Redefine the directory where Shorewall keeps its state information. vardir-lite - Redefine the directory where Shorewall Lite keeps its state information. zones - Declare Shorewall zones.
Section 8 — Administrative Commands
shorewall - /sbin/shorewall command syntax and semantics. shorewall-init - Companion package that allows for automatic start/stop of other Shorewall products based on network events. shorewall-lite - /sbin/shorewall-lite command syntax and semantics.
shorewall-docs-xml-4.5.21/two-interface_ru.xml0000644000175000017500000021631312222401136021221 0ustar teastepteastep
Основной файервол с двумя интерфейсами 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. Эта статья применима для Shorewall версии 3.0 и выше. Если Вы работаете с более ранней версией Shorewall чем Shorewall 3.0.0, тогда смотрите документацию для этого выпуска.
Введение Установка Linux системы как файервола для небольшой сети довольно простая задача, если Вы понимаете основы и следуете документации. Это руководство не пытается ознакомить Вас со всеми особенностями Shorewall. Оно больше сфокусировано на том, что требуется для настройки Shorewall в наиболее типичных конфигурациях: Linux система, используемая как файервол/маршрутизатор для небольшой локальной сети. Один внешний (публичный) IP-адрес. Если Вы имеете более одного публичного IP-адреса, это руководство не то, что Вам нужно. Смотрите вместо этого Руководство по установке Shorewall. Интернет-соединение посредством кабельного модема, DSL, ISDN, Frame Relay, коммутирумой линии ... Вот схема типичной установки:
Общая конфигурация файервола с двумя интерфейсами
Системные требования Shorewall требует, чтобы у Вас был установлен пакет iproute/iproute2 (на RedHat, этот пакет называется iproute). Вы можете определить установлен ли этот пакет по наличию программы ip на Вашем файерволе. Как root, Вы можете использовать команду which для проверки наличия этой программы:[root@gateway root]# which ip /sbin/ip [root@gateway root]#
Перед тем как начать Я рекомендую Вам прочитать все руководство для первоначального ознакомления, а лишь затем пройти его снова, внося изменения в Вашу конфигурацию. Если Вы редактируете Ваши файлы конфигурации на Windows системе, Вы должны сохранить их как Unix файлы в том случае, если Ваш редактор поддерживает эту возможность, иначе Вы должны пропустить их через программу dos2unix перед тем как использовать их. Аналогично, если Вы копируете конфигурационный файл с Вашего жесткого диска с Windows на дискету, Вы должны воспользоваться dos2unix для копии перед ее использованием с Shorewall. Windows версия dos2unix Linux версия dos2unix
Соглашения Места, в которых рекомендуется вносить изменения, отмечены как . Замечания по настройке уникальные для проекта LEAF/Bering, отмечены как .
PPTP/ADSL Если У Вас есть ADSL модем и Вы используете PPTP для взаимодействия с сервером на этом модеме, Вы должны сделать изменения рекоммендуемые здесь в дополнение к тем, что описаны в последующих шагах. ADSL с PPTP наиболее распространен в Европе, особенно в Австрии.
Концепции Shorewall Конфигурационные файлы Shorewall находятся в директории /etc/shorewall -- в случае простой установки Вам необходимо иметь дело только с немногими из них, как описано в этом руководстве. Замечание для пользователей Debian Если Вы при установке пользовались .deb, Вы обнаружите, что директория /etc/shorewall пуста. Это сделано специально. Поставляемые шаблоны файлов конфигурации Вы найдете на вашей системе в директории /usr/share/doc/shorewall-common/default-config. Просто скопируйте нужные Вам файлы из этой директории в /etc/shorewall и отредактируйте копии. Заметьте, что Вы должны скопировать /usr/share/doc/shorewall-common/default-config/shorewall.conf и /usr/share/doc/shorewall=common/default-config/modules в /etc/shorewall даже если Вы не будете изменять эти файлы. После того как Вы установили Shorewall, Вы можете найти примеры файлов настроек в следующих местах: Если Вы при установке использовали RPM, примеры будут находится в поддиректории Samples/two-interface директории с документацией Shorewall. Если Вы не знаете где расположена директория с документацией Shorewall, Вы можете найти примеры используя команду: ~# 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/routestopped /usr/share/doc/packages/shorewall/Samples/two-interfaces/rules /usr/share/doc/packages/shorewall/Samples/two-interfaces/zones ~# Если Вы установили Shorewall из tarball'а, примеры находятся в директории Samples/two-interface внутри tarball'а. Если же Вы пользовались пакетом .deb, примеры находятся в директории/usr/share/doc/shorewall-common/examples/two-interface. По мере того как мы будем знакомится с каждым файлом, я надеюсь, что Вы просмотрите реальный файл на вашей системе -- каждый файл содержит детальное описание конфигурационных инструкций и значений по умолчанию. Shorewall видит сеть, в которой он работает, как состоящую из набора зон(zones). В примере конфигурации с двумя интерфейсами, определены следующие зоны: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 loc ipv4 Зоны Shorewall описаны в файле /etc/shorewall/zones. Заметьте, что Shorewall рассматривает систему файервола как свою собственную зону. При обработке файла /etc/shorewall/zones имя зоны файервола (fw в примере выше) храниться в переменной shell $FW, которая может использоваться во всей конфигурации Shorewall для ссылки на сам файервол. Правила о том какой трафик разрешен, а какой запрещен выражаются в терминах зон. Вы отражаете Вашу политику по умолчанию для соединений из одной зоны в другую в файле/etc/shorewall/policy. Вы определяете исключения из политики по умолчанию в файле /etc/shorewall/rules. Для каждого запроса на соединение входящего в файервол, запрос сначала проверяется на соответствие файлу /etc/shorewall/rules. Если в этом файле не найдено правил соответствующих запросу на соединение, то применяется первая политика из файла /etc/shorewall/policy, которая соответсвует запросу. Если есть общее действие (common action) определенное для политики в файле /etc/shorewall/actions или /usr/share/shorewall/actions.std, тогда это действие выполняется перед тем как . Файл /etc/shorewall/policy, входящий в пример с двумя интерфейсами, имеет следующие политики: #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT net all DROP info all all REJECT info В примере с двумя интерфейсами строка показанная внизу закомментирована. Если Вы хотите, чтобы Ваш файервол имел полный доступ к серверам Интернет, раскомментируйте эту строчку. #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST $FW net ACCEPTПолитики приведенные выше будут: разрешать все запросы на соединение из Вашей локальной сети в Интернет; отбрасывать (игнорировать) все запросы на соединение из Интернет к Вашему файерволу или локальной сети; Опционально разрешать все запросы на соединение с файервола в Интернет (если Вы раскомментировали дополнительную политику); отвергать все другие запросы на соединение (Shorewall требует наличия такой политики, применимой для всех остальных запросов). Важно отметить, что политики Shorewall (и правила) ссылаются на соединения, а не на поток пакетов. С политикой определенной в файле /etc/shorewall/policy, показанной выше, разрешены соединения из зоны loc в зону net, хотя на сам файервол соединения из зоны loc не разрешены. В данный момент Вы можете отредактировать ваш файл /etc/shorewall/policy и внести изменения, какие Вы считаете необходимыми.
Сетевые интерфейсы Файервол имеет два сетевых интерфейса. Если соединение с Интернет осуществляется при помощи кабельного или DSL Модема, Внешним интерфейсом будет тот ethernet-адаптер (например, eth0), который подсоединен к этому Модему, если же Вы соединены посредством протокола Point-to-Point Protocol over Ethernet (PPPoE) или Point-to-Point Tunneling Protocol (PPTP), то в этом случае Внешним интерфейсом будет PPP интерфейс (например, ppp0). Если Вы подсоединены через обычный модем, Вашим Внешним интерфейсом будет также ppp0. Если Вы соединяетесь используя ISDN, Внешним интерфейсом будет ippp0. Если Ваш внешний интерфейс - это ppp0 или ippp0, тогда Вы можете захотеть установить переменную CLAMPMSS=yes в /etc/shorewall/shorewall.conf. Ваш Внешний интерфейс будет ethernet-адаптер (eth0 or eth1) и будет соединен с хабом или коммутатором. Другие Ваши компьютеры будут соединены с тем же хабом/коммутатором (заметьте: если Вы имеете только одну внутреннюю систему, Вы можете соединить файервол с этим компьютером напрямую, используя кроссоверный (cross-over) кабель. НЕ подсоединяйте внутренний и внешний интерфейсы к одному т тому же хабу или коммутатору исключая время тестирование.Вы можете провести тестирование используя данную конфигурацию, если Вы указали параметр ARP_FILTER в /etc/shorewall/interfaces для всех интерфейсов подсоединенных к общему хабу/коммутатору. Использовать такие установки на рабочем файерволе строго не рекоммендуется. Пример конфигурации Shorewall с двумя интерфейсами подразумевает, что внешний интерфейс - это eth0, а внутренний - eth1. Если Ваша конфигурация отличается, Вы должны будете изменить пример файл /etc/shorewall/interfaces соответственно. Пока Вы здесь, Вы возможно захотите просмотреть список опций, специфичных для интерфейса. Вот несколько подсказок: Если Ваш внешний интерфейс ppp0 или ippp0, Вы можете заменить detect(обнаружить) во втором столбце на -(знак минус в ковычках). Если Ваш внешний интерфейс ppp0 или ippp0 или Вы имеете статический IP-адрес, Вы можете удалить dhcp из списка опций. Если Ваш внешний интерфейс является мостом, созданным с использованием утилиты brctl, тогда Вы должны добавить опцию routeback в список опций.
IP-адреса Перед тем как идти дальше, мы должны сказать несколько слов о Internet Protocol (IP)-адресах. Обычно, Ваш Интернет-провайдер(Internet Service Provider - ISP) назначает Вам один IP-адрес. Этот адрес может быть назначен статически, при помощи Протокола Динамического Конфигурирования Хостов (Dynamic Host Configuration Protocol - DHCP), в процессе установки Вами коммутированного соединения (обычный модем), или при установке Вами другого типа PPP (PPPoA, PPPoE и т.д.) соединения. В последнем случае Ваш ISP может назначит Вам статический IP-адрес; что означает, что Вы настраиваете внешний интерфейс Вашего файервола на использование этого адреса постоянно. Как бы ни был назначен Вам внешний адрес, он будет разделяться между всеми Вашими системами при доступе в Интернет. Вы должны будете назначить свои собственные адреса в Вашей внутренней сети (внутренний интерфейс на Вашем файерволе, плюс другие Ваши компьютеры). RFC-1918 резервирует несколько Частных (Private) IP-адресов для этих целей: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 Перед запуском Shorewall, Вы должны взглянуть на IP-адрес Вашего внешнего интерфейса и если он входит в один указанных выше пазонов, Вы должны удалить опцию norfc1918 из строки для внешнего интерфейса в файле /etc/shorewall/interfaces. Вы можете захотеть назначить Ваши адреса из такой же подсети (subnet). Для наших целей мы можем рассматривать подсеть состоящую из диапазона адресов x.y.z.0 - x.y.z.255. Такая подсеть будет иметь Маску Подсети (Subnet Mask) - 255.255.255.0. Адрес x.y.z.0 зарезервирован как Адрес Подсети (Subnet Address), а x.y.z.255 как Широковещательный Адрес Подсети (Subnet Broadcast Address). В Shorewall подсеть описывается с использованием нотации Бесклассовой Междоменной Маршрутизации (Classless InterDomain Routing - CIDR notation) с адресом посети оканчивающимся /24. 24 указывает число непрерывных ведущих бит установленных в 1 слева в маске подсети. Диапазон: 10.10.10.0 - 10.10.10.255 Адрес подсети: 10.10.10.0 Широковещательный адрес: 10.10.10.255 Нотация CIDR: 10.10.10.0/24 Удобно назначать внутреннему интерфейсу либо первый используемый адрес подсети (10.10.10.1 в примере выше), либо последний используемый адрес (10.10.10.254). Одна из целей разбиения на подсети - это позволить всем компьютерам в подсети понимать с какими другими компьютерами можно взаимодействовать напрямую. При взаимодействии с системами находящимися вне подсети, системы посылают пакеты через шлюз (маршрутизатор) (gateway (router)). Ваши локальные компьютеры (computer 1 и computer 2 на диаграмме выше) должны быть сконфигурированы так, чтобы IP-адресом их маршрутизатора по умолчанию был IP-адрес внутреннего интерфейса файервола. Короткая предшествующая дискуссия лишь поверхностно затронула вопросы связанные с подсетями и маршрутизацией. Если Вы заинтересованы узнать больше об IP-адресации и маршрутизации, я очень рекомендую Основы IP: Что нужно знать каждому об адресации и маршрутизации (IP Fundamentals: What Everyone Needs to Know about Addressing & Routing), Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0 (link). Оставшаяся часть руководства расчитана на то, что Вы имеете сеть, сконфигурированную так, как показано здесь: Маршрутизатором по умолчанию для computer 1 и 2 должен быть 10.10.10.254. Ваш ISP может назначить Вашему внешнему интерфейсу адрес из RFC-1918. Если этот адрес из подсети 10.10.10.0/24, тогда Вы должны будете выделить ДРУГУЮ подсеть RFC-1918 для вашей локальной подсети.
IP-маскарадинг (SNAT) Адреса зарезервированные RFC-1918 иногда называют немаршрутизируемыми потому, что магистральные маршрутизаторы Интернет не переправляют пакеты, которые имеют адрес назначения из RFC-1918. Когда одна из Ваших локальных систем (допустим computer 1) посылает запрос на соединение хосту в Интернете, файервол должен выполнить Трансляцию Сетевого Адреса (Network Address Translation - NAT). Файервол перезаписывает адрес источника в пакете адресом внешнего интерфейса файервола; другими словами, файервол делает так, чтобы это выглядело как файервол сам инициируетсоединение. Это необходимо так как хост назначения должен быть способен направить пакеты назад файерволу через маршрутизаторы (вспомним, что пакеты с адресом назначения зарезервированным RFC-1918 не могут быть маршрутизированы через Интернет и следовательно удаленный хост не сможет адресовать ответ на computer 1). Когда файервол принимает ответный пакет, он перезаписывает адрес назначения обратно в 10.10.10.1 и переправляет пакет на computer 1. На Linux системах, описанный выше процесс называют IP-маскарадингом (IP Masquerading), но Вы будете также встречать термин Преобразование Сетевого Адреса Источника (Source Network Address Translation - SNAT). Shorewall следует соглашению используемому Netfilter: Masquerade описывает случай, когда Вы позволяете своему файерволу автоматически определять адрес внешнего интерфейса. SNAT используют в случае, когда Вы определенно указываете адрес источника, который Вы хотите использовать для покидающих Вашу локальную сеть пакетов. В Shorewall оба режима Маскарадинг (Masquerading) и SNAT конфигурируются записями в файле /etc/shorewall/masq. Вы будете обычно использовать Маскарадинг, если Ваш внешний IP-адрес - динамический и SNAT, если внешний IP-адрес - статический. Если Ваш внешний интерфейс файервола - eth0, Вам не нужно изменять файл из примера. В противном случае, отредактируйте /etc/shorewall/masq и измените первый столбец на имя Вашего внешнего интерфейса и второй столбец на имя Вашего внутреннего интерфейса. Если Ваш внешний IP-адрес - статический, Вы можете ввести его в третьем столбце записи файла /etc/shorewall/masq если Вам нравиться, хотя Ваш файервол будет прекрасно работать, даже если Вы оставите этот столбец пустым. Вводя Ваш статический IP-адрес в третьем столбце, Вы делаете обработку исходящих пакетов немного более эффективной. Если Вы используете пакет Debian, проверьте пожалуйста Ваш файл shorewall.conf, чтобы убедиться, что следующее установлено правильно; если нет, измените это соответственно: IP_FORWARDING=On
Перенаправление портов (DNAT) Одной из Ваших целей может быть запуск одного или более серверов на Ваших локальных компьютерах. Так как эти компьютеры имеют адреса из RFC-1918, то клиентам из Интернет невозможно соединиться напрямую с ними. Это более невозможно для тех клиентов, кто адресует свои запросы для соединения на файервол, который переписывает адрес назначения на адрес Вашего сервера и переправляет пакет на этот сервер. Когда Ваш сервер отвечает, файервол автоматически выполняет SNAT для перезаписи адреса источника в ответе. Описанный выше процесс называется Перенапрвление Портов (Port Forwarding) или Преобразование Сетевого Адреса Назначения (Destination Network Address Translation - DNAT). Вы настраиваете перенаправление портов при помощи правил DNAT в файле /etc/shorewall/rules. Основная форма примерного правила перенаправления портов в /etc/shorewall/rules такая:#ACTION SOURCE DEST PROTO DEST PORT(S) DNAT net loc:<server local ip address>[:<server port>] <protocol> <port>Shorewall имеет макрос (macros) для многих популярных приложений. Смотрите в /user/share/shorewall/macro.*, чтобы увидеть, что доступно в Вашем релизе. Макрос упрощает создание правил DNAT предоставляя протокол и порт(ы) как показано ниже. Web-сервер Вы запускаете Web-сервер на computer 2 и Вы хотите перенаправить входящие на порт 80 TCP-пакеты на эту систему: #ACTION SOURCE DEST PROTO DEST PORT(S) Web/DNAT net loc:192.168.1.5 FTP-сервер Вы запустили FTP-сервер на computer 1, так что Вы хотите перенаправить входящие на порт 21 TCP-пакеты на эту систему: #ACTION SOURCE DEST PROTO DEST PORT(S) FTP/DNAT net loc:10.10.10.1Для FTP Вы должны также буете иметь отслеживание FTP соединений (connection tracking) и поддержку NAT в Вашем ядре. Для ядер, предоставляемых продавцами дистрибутивов, это означает, что должны быть загружены модули ip_conntrack_ftp и ip_nat_ftp. Shorewall автоматически загрузит эти модули если они доступны и расположены в стандартных местах внутри /lib/modules/<kernel version>/kernel/net/ipv4/netfilter. Нужно иметь в виду пару важных моментов: Вы должны протестировать приведенные выше правила для клиентов вне Вашей локальной сети (т.е., не тестировать из браузера, запущенного на computer 1 или 2 или на файерволе). Если Вы хотите иметь доступ к Вашему Web-серверу и/или FTP-серверу с Вашего файервола, используя IP-адрес Вашего внешнего интерфейса, смотрите Shorewall FAQ #2. Многие ISP блокируют входящие запросы для соединения на порт 80. Если у Вас есть проблемы при соединении с Вашим Web-сервером, попробуйте следующее правило и попытайтесь соединиться с портом 5000 (например, подключитесь к http://w.x.y.z:5000, где w.x.y.z - Ваш внешний IP). #ACTION SOURCE DEST PROTO DEST PORT(S) DNAT net loc:10.10.10.2:80 tcp 5000 В этом месте измените /etc/shorewall/rules добавив любое правило DNAT, какое Вам необходимо. Когда тестируете правила DNAT похожие на те, что приведены выше, Вы должны тестировать с клиента ИЗВНЕ ВАШЕГО ФАЙЕРВОЛА (в зоне net). Вы не можете протестировать эти правила изнутри файервола! Советы по разрешению проблем с DNAT, смотрите в FAQs 1a и 1b.
Сервер Доменных Имен (Domain Name Server - DNS) Обычно, когда Вы соединяетесь с Вашим ISP, как часть получения IP-адреса будет автоматически настроен резольвер Сервиса Доменных Имен (Domain Name Service - DNS) Вашего файервола (например, будет записан файл /etc/resolv.conf). Как альтернатива, Ваш ISP может сообщить Вам IP-адреса пары DNS-серверов, чтобы Вы вручную указали их как Ваши первичный и вторичный сервера имен. Вне зависимости от того как Вы настроете DNS на Вашем файерволе, на Вас лежит ответственность за то как будет настроен резольвер на Ваших внутренних системах. Вы можете применить один из двух подходов: Вы можете настроить Ваши внутренние системы на использование серверов имен Вашего ISP. Если Ваш ISP дал Вам адреса этих серверовthe или если эти адреса доступны на Web-сайте, Вы можете настроить Ваши внутренние системы на использование этих адресов. Если эта информация недоступна, загляните в /etc/resolv.conf на Вашем файерволе -- сервера имен указаны в записях nameserver этого файла. Вы можете настроить Кэширующий Сервер Имен (Caching Name Server) на Вашем файерволе. Red Hat имеет RPM для кэширующего сервера имен (которому также необходим пакет bind-RPM), а для пользователей Bering существует dnscache.lrp. Если Вы пойдете этим путем, Вы настраиваете Ваши внутренние системы на использование самого файервола как первичного (и только) сервера имен. Вы используете внутренний IP-адрес файервола (10.10.10.254 в примере выше) для адреса сервера имен, если Вы запускаете сервер имен на Вашем файерволе. Чтобы позволить Вашим локальным системам общаться с Вашим кэширующим сервером имен, Вы должны открыть доступ к порту 53 (оба UDP и TCP) на файерволе из внутренней сети. Вы можете сделать это, добавив следующее правило в файл /etc/shorewall/rules.#ACTION SOURCE DEST PROTO DEST PORT(S) DNS/ACCEPT loc $FW
Другие соединения Пример с двумя интерфейсами включает следующие правила:#ACTION SOURCE DEST PROTO DEST PORT(S) DNS/ACCEPT $FW netЭто правило разрешает доступ к DNS с Вашего файервола и может быть удалено, если Вы раскомментировали строку в /etc/shorewall/policy, разрешающую все соединения с файервола в Интернет. В показанном выше правиле DNS/ACCEPT - это пример привлечения макроса (macro invocation). Shorewall включает множество макросов (смотри /usr/share/shorewall/macro.*) и Вы можете добавить Ваш собственный. Вам не обязательно использовать предопределенные макросы при написании правил в файле /etc/shorewall/rules; Shorewall будет запускаться немного быстрее, если Вы будете писать Ваши правила напрямую, чем при использовании макросов. Правил, показанное выше может быть также записано как:#ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT $FW net udp 53 ACCEPT $FW net tcp 53 В случаях когда Shorewall не имеет предопределенных макросов, отвечающих Вашим потребностям, Вы можете либо определить свой собственный макрос, либо просто записать соответствующие правила напрямую. Эта страница может помочь Вам в случае, если Вы не знаете используемые протокол и порт. Пример также включает: #ACTION SOURCE DEST PROTO DEST PORT(S) SSH/ACCEPT loc $FW Это правило разрешает Вам запускать SSH-сервер на Вашем файерволе и соединяться с ним с Ваших локальных систем. Если Вы хотите разрешить другие соединения с Вашего файервола к другим системам, основной формат использования макроса такой:#ACTION SOURCE DEST PROTO DEST PORT(S) <macro>/ACCEPT $FW <destination zone>Основной формат при отсутствии предопределенных макросами действий такой:#ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT $FW <destination zone> <protocol> <port> Web-сервер на файрволе Вы хотите запустить Web-сервер на Вашем файерволе: #ACTION SOURCE DEST PROTO DEST PORT(S) Web/ACCEPT net $FW Web/ACCEPT loc Эти два правила, конечно, должны быть добавлены к тем правилам, которые указаны выше в абзаце Вы можете настроить Кэширующий Сервер Имен на Вашем файерволе. Если Вы не знаете какой порт и протокол использует конкретное приложение, смотрите здесь. Я не рекоммендую разрешать telnet в/из Интернет потому, что он использует открытый текст (даже для передачи имени и пароля!). Если Вы хотите иметь доступ к командному интерпретатору Вашего файервола из Интернет, используйте SSH: #ACTION SOURCE DEST PROTO DEST PORT(S) SSH/ACCEPT net $FW Пользователи дистрибутива Bering захотят добавить следующие два правила для совместимости с конфигурацией Shorewall от Jacques.#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 Запись 1 разрешает использование кэширующего DNS. Запись 2 разрешает работу weblet. Теперь Вы можете отредактировать Ваш файл /etc/shorewall/rules, добавляя или удаляя другие соединения по необходимости.
Что нужно помнить Вы не можете Ваш файервол изнутри. Только потому, что Вы посылаете запросы на внешний IP-адрес Вашего файервола не означает, что запросы будут ассоциированы с внешним интерфейсом или зоной net. Любой трафик, создаваемый из локальной сети будет ассоциироваться с Вашим локальным интерфейсом и будет воспринят как трафик loc->fw. IP-адреса - это свойства систем, а не интерфейсов. Ошибочно верить, что Ваш файервол способен переправит пакеты только потому, что Вы можете пропинговать IP-адрес всех интерфейсов файервола из локальной сети. Единственное заключение, которое Вы можете вынести из такого успешного пингования - это наличие рабочей связи между локальной системой и файерволом и то, что Вы, возможно, правильно указали маршрутизатор по умолчанию на локальной системе. Все IP-адреса, настроенные на интерфейсах файервола, принадлежат зоне $FW (fw). Если 192.168.1.254 - это IP-адрес Вашего внутреннего интерфейса, то Вы можете написать $FW:192.168.1.254 в правиле, но Вы не можете написать loc:192.168.1.254. Также не играет роли добавление адреса 192.168.1.254 в зону loc при помощи записи в файле /etc/shorewall/hosts. Ответные пакеты НЕ следуют автоматически обратно тем маршрутом, который использовал исходный запрос. Все пакеты маршрутизируются согласно таблице маршрутизации каждого хоста на всем пути. Этот вопрос обычно встает когда людч устанавливают файервол Shorewall параллельно с имеющимся шлюзом и пытаются использовать DNAT сквозь Shorewall без изменения шлюза по умолчанию системы, принимающей переправленные запросы. Запросы проходят сквозь файервол Shorewall, где изменяется IP-адрес назначения, но ответы уходят неизмененными через старый шлюз. Shorewall сам не имеет представления о внутренней и внешней стороне. Воплощение этих концепций зависит от того, как настроен Shorewall.
Запуск и останов Вашего файервола Процедура установки настраивает Вашу систему для запуска Shorewall при загрузке системе, но запуск остается отключен, так что система не будет пытаться запустить Shorewall до полного завершения конфигурирования. Как только Вы полностью завершите конфигурирование Вашего файервола, Вы можете включить запуск Shorewall, отредактировав файл /etc/shorewall/shorewall.conf и установив параметр STARTUP_ENABLED=Yes. Пользователи пакета .deb должны отредактировать файл /etc/default/shorewall и установить параметр STARTUP=1. Вы должны разрешить запуск путем редактирования файла /etc/shorewall/shorewall.conf и установки параметра STARTUP_ENABLED=Yes. Файервол запускается при помощи команды shorewall start и останавливается при помощи shorewall stop. Когда файервол остановливается, маршрутизация разрешается на те хосты, которые указаны в /etc/shorewall/routestopped. Запущенный файервол может быть перезапущен при помощи команды shorewall restart. Если Вы хотите полностью удалить изменения сделанные Shorewall из конфигурации Вашего Netfilter, используйте команду shorewall clear. Пример с двумя интерфейсами предполагает, что Вы хотите разрешить маршрутизацию к/из eth1 (локальная сеть) когда Shorewall остановлен. Если Ваша локальная сеть не подсоединена к eth1 или Вы не хотите разрешать доступ к/из других хостов, измените файл /etc/shorewall/routestopped соответственно. Если Вы подсоединены к Вашему файерволу из Интернет, не используйте команду shorewall stop если Вы не добавили запись для IP-адреса, с которого Вы подсоединены, в /etc/shorewall/routestopped. Также, я не рекоммендую использовать shorewall restart; лучше создать альтернативную конфигурацию и протестировать ее при помощи команды shorewall try.
Дополнительно рекоммендуемая литература Я особо рекоммендую просмотреть Вам страницу Общих Особенностей Файлов Конфигурации -- она содержит полезные советы об особенностях Shorewall, делающую администрирование Вашего файервола проще.
Добавление сегмента беспроводной связи к Вашему файерволу с двумя интерфейсами Как только Вы будете иметь работающую конфигурацию с двумя интерфейсами, следующий логический шаг - добавление беспроводной сети. Первый шаг включает добавление дополнительной сетевой карты в Ваш файервол, либо карты беспроводного интерфейса, либо Ethernet-карты, которая соединена с Точкой Беспроводного Доступа (Wireless Access Point). Когла Вы добавляете сетевую карту, она необязательно будет определена как следующая по порядку сетевой интерфейс. Например, если Вы имеете две карты Ethernet в Вашей системе (eth0 и eth1) и Вы добавляете третью карту, которая использует такой же драйвер как и одна из имеющихся, то эта третья карта необязательно будет определена как eth2; она может определиться как eth0 или eth1! Вы можете оставить все как есть, либо можете переставлять карты в слотах до тех пор, пока новая карта не будет определена как eth2. Ваша новая сеть будет выглядеть примерно так, как показано на следующем рисунке. Во-первых необходимо отметить, что компьютеры в Вашей беспроводной сети будут принадлежать другой подсети, чем те, что находяться в проводной локальной сети. В примере выше мы выбрали для использования сеть 10.10.11.0/24. Computers 3 и 4 должны быть настроены с IP-адресом маршрутизатора по умолчанию 10.10.11.254. Во-вторых мы решили включить беспроводную сеть как часть зоны loc. Поскольку Shorewall по умолчанию разрешает внутризонный трафик, трафик может свободно перемещаться между локальными проводной и беспроводной сетями. Необходимо выполнить всего-лишь два изменения в настройках Shorewall: Нужно добавить запись для интерфейса беспроводной сети в файл /etc/shorewall/interfaces. Если беспроводной интерфейс wlan0, то запись может выглядеть так: #ZONE INTERFACE BROADCAST OPTIONS loc wlan0 detect maclist Как показано выше, я рекоммендую использовать опцию maclist для беспроводного сегмента. Добавив записи для computers 3 и 4 в файл /etc/shorewall/maclist, Вы можете быть уверенными, что Вашими соседями не сможет стать любой, используя Ваше Интернет соединение. Начните без этой опции, а когда у Вас все заработает, добавьте ее и настройте Ваш файл /etc/shorewall/maclist. Вам необходимо добавить запись в файл /etc/shorewall/masq для маскарадинга трафика из беспроводной сети в Интернет. Если Ваш Интернет-интерфейс eth0 и Ваш беспроводной интерфейс wlan0, то запись будет такой: #INTERFACE SUBNET ADDRESS eth0 wlan0 Еще одно замечание. Для того, чтобы между беспроводной и проводной сетями работала сеть Microsoft, Вам необходим либо WINS-сервер, либо PDC. Я лично пользуюсь Samba, настроенной как WINS-сервер, работающей на моем файерволе. Запуск WINS-сервера на Вашем файерволе потребует правил, перечисленных в документации Shorewall/Samba.
shorewall-docs-xml-4.5.21/upgrade_issues.xml0000644000175000017500000015470712222401136020776 0ustar teastepteastep
Upgrade Issues Tom Eastep 2002 2003 2004 2005 2006 2007 2008 2009 2012 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.
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.
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
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 LOG # LEVEL 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-4.5.21/traffic_shaping_ru.xml0000644000175000017500000021311512222401136021576 0ustar teastepteastep
Управление трафиком и шейпинг трафика Tom Eastep Arne Bernin 2001-2007 Thomas M. Eastep 2005 Arne Bernin & Thomas M. Eastep 2007 Russian Translation: Grigory Mokhin Этот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии 1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке GNU Free Documentation License. Управление трафиком - это сложная тема, и не следует ожидать от сообщества Shorewall готовых ответов на возникающие в связи с этим вопросы. Поэтому, если вам нужны готовые рецепты, как нажать кнопку, чтобы все заработало само, лучше даже не пытайтесь организовать управление трафиком с помощью Shorewall. Вас ожидают неприятные разочарования, и вряд ли кто-либо сможет вам помочь. Иначе говоря, чтение только документации Shorewall не будет достаточным для понимания раскрываемых здесь тем. Как минимум, потребуется обратиться к следующим дополнительным источникам: LARTC HOWTO: http://www.lartc.org Руководство по HTB: http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm Некоторые документы с сайта http://www.netfilter.org/documentation/index.html#documentation-howto. Рекомендуем ознакомиться с очень хорошим руководством Оскара Андреассона. Вывод команды man iptables
Введение Начиная с версии 2.5.5 в Shorewall реализована встроенная поддержка управления трафиком и шейпинга трафика. В более ранних версиях эти возможности были ограниченными. Можно было использовать собственный сценарий tcstart (это можно и сейчас), но, за исключением файла tcrules, в файлах конфигурации Shorewall не была предусмотрена возможность определения классов и дисциплин очередей. До сих пор поддержка управления трафиком является неполной, например, не поддерживаются все опции (и особенно различные алгоритмы очередей) из ядра Linux, но для большинства случаев она будет достаточной. Если у вас уже есть сценарий для управления трафиком, который вы собираетесь использовать и в будущем, то соответствующие инструкции приведены по ссылке ниже в этом документе. Для того чтобы это заработало, требуется включить поддержку управления трафиком в ядре и в Shorewall, как описано далее.
Управление трафиком и шейпинг трафика в Linux В этом разделе кратко описано, как работает управление трафиком в Linux. Даже если этого должно быть достаточно для настройки управления трафиком в файлах конфигурации Shorewall, мы очень рекомендуем внимательно прочитать руководство Linux Advanced Routing and Shaping HOWTO. Во время написания этого документа текущей версией была 1.0.0. Начиная с версии 2.2, в Linux реализованы полные возможности управления трафиком. Предусмотрены различные алгоритмы, которые применяются для приоритизации очередей пакетов, выходящих с интерфейса. Стандартный алгоритм называется pfifo, и, как следует из самого названия, это очередь типа первым пришел - первым ушел. Фактически при этом никакого управления трафиком не происходит, и если какое-то соединение забивает весь канал, то этот алгоритм не сможет этого предотвратить. Для управления трафиком в Shorewall используются два алгоритма, HTB (иерархический набор маркеров) и SFQ (очередь с равноправным стохастическим упорядочением). SFQ использует простую схему: отслеживаются все соединения (tcp или udp), и трафик распределяется между ними. Обычно это работает хорошо. HTB позволяет определить набор классов, между которыми распределяется трафик. Для каждого класса можно указать минимальную и максимальную полосу пропускания, а сами классы упорядочить в иерархическую структуру, чтобы классы с меньшим приоритетом получали доступ к каналу только в том случае, если запросы более важных классы удовлетворены. Встроенные функции управления трафиком в Shorewall позволяют определить такие классы и указать для них полосу пропускания. Внутри самих классов используется SFQ, чтобы их различные внутренние потоки данных обрабатывались как равноправные. Управлять можно только исходящим трафиком. Причина этого состоит в том, что входящие пакеты уже пришли на сетевую плату, и нужно решить, что с ними делать. Их можно только сбросить, но особого смысла в этом не будет, поскольку пакет уже пришёл, пройдя через узкое место - входящий канал. Следующим узким местом может быть интерфейс, с которого уходит этот пакет, и именно на нём может образовываться очередь. Поэтому определение очередей для входящих пакетов не будет особенно полезным, эти пакеты просто нужно передать как можно быстрее на исходящий интерфейс. Есть одно исключение. Если ограничить входящий трафик значением чуть меньшим, чем фактическая пропускная способность канала, то будет исключено образование очередей на другом конце соединения. Это бывает полезно, если управление потоком на другом конце канала невозможно, а сам он подключен к сети по более быстрому каналу, например, если вы подключены к провайдеру по кабельному модему или модему DSL, а маршрутизатор провайдера подключен к быстрому магистральному каналу. Поэтому, если отбрасывать слишком быстро приходящие пакеты, то основной протокол сможет это обнаружить и снизить скорость соединения. В TCP такой механизм встроен, в UDP не встроен, но протокол, работающий поверх UDP, может иметь такой механизм. В таких случаях создание очередей будет иметь неприятные последствия, если есть пакеты, которые должны проходить в первую очередь, как, например, VoIP или ssh. Для таких соединений важно, чтобы пакеты проходили с минимальной задержкой. Для других пакетов, таких как загрузка по HTTP, задержка на несколько секунд не будет иметь значения. Если на другом конце канала образуется очередь, а маршрутизатор не поддерживает QoS или биты QoS настроены неверно, то пакеты, для которых важна минимальная задержка, будут ждать в той же очереди, что и менее важные пакеты загрузки по HTTP, и задержка может быть большой. Управление исходящим трафиком достигается посредством распределения потока пакетов по классам. Класс связан ровно с одним сетевым интерфейсом и имеет ряд атрибутов: PRIORITY - используется для указания приоритетов классов, к которым относятся отправляемые пакеты. Приоритет - это число, при этом 1 задаёт наивысший приоритет, 2 - следующий по важности и т.д. RATE - скорость, то есть минимальная гарантированная пропускная способность, которая должна обеспечиваться для класса, когда возрастает нагрузка на канал. Классы с более высоким приоритетом (меньшие значения PRIORITY) обслуживаются даже в том случае, если заданы другие классы с гарантированной пропускной способностью, но низшим приоритетом (большие значения PRIORITY). CEIL - ограничение, максимальная полоса пропускания, которая отводится для класса, когда канал свободен. MARK - метка. В Netfilter предусмотрены способы маркировки пакетов. Метки пакетов - это числа. В Shorewall они могут принимать значение от 1 до 255. Метки пакетов присваиваются различным типам пакетов согласно правилам, заданным в файле /etc/shorewall/tcrules. Для каждого интерфейса необходимо задать один класс, который будет классом по умолчанию. К этому классу будут относиться непомеченные данные, то есть пакеты, для которых не задана метка в файле /etc/shorewall/tcrules. Netfilter также поддерживает метки соединений. Метки соединений можно присвоить соединениям в правилах /etc/shorewall/tcrules, можно скопировать метку пакета в метку соединения (SAVE), или скопировать метку соединения в метку пакета (RESTORE).
Конфигурация ядра Linux Для работы требуется ядро не ниже 2.4.18. На рисунке показаны опции ядра, которые необходимо включить. Для встроенной поддержки необходимы опции HTB scheduler, Ingress scheduler, PRIO pseudoscheduler и SFQ queue. Прочие планировщики или алгоритмы очередей необязательны. Также требуются классификаторы u32 и fw из главного меню Networking Options (не показаны). На следующем рисунке показано, как я настроил QoS у себя в ядре 2.6.13: Конфигурация ядра изменилась в 2.6.16 -- вот мои рекомендации.
Включение поддержки TC в Shorewall Поддержку TC требуется включить независимо от того, применяются ли встроенные функции или вы используете собственный сценарий tcstart. Для включения встроенных функций управления трафиком в Shorewall выполните следующее: Задайте TC_ENABLED равным "Internal" в /etc/shorewall/shorewall.conf. Если TC_ENABLED=Yes, то Shorewall будет искать внешний файл tcstart (см. далее). Если задать параметр CLEAR_TC в /etc/shorewall/shorewall.conf равным Yes, то при запуске, перезапуске и остановке Shorewall будет сбрасываться текущая конфигурация управления трафиком. Обычно именно это и требуется при работе с встроенными функциями, а также с собственным сценарием tcstart. Следующие действия зависят от того, применяются ли встроенные функции или собственный сценарий. Подробнее это объясняется в следующих разделах.
Работа с встроенными функциями управления трафиком и шейпинга Встроенные в Shorewall функции управления трафиком - это тонкая оболочка для очереди входящих пакетов (ingress qdisc), HTB и SFQ. Эта оболочка позволяет выполнить следующие задачи: Определить классы HTB в файлах конфигурации Shorewall. Включить загрузку конфигурации управления трафиком вместе с загрузкой правил фильтрации пакетов и правил для меток. Распределить пакеты по классам HTB согласно значениям TOS. Отнести исходящие пакеты TCP ACK к классу HTB. Распределить пакеты по классам HTB согласно значениям меток пакетов. Встроенные в Shorewall функции управления трафиком ограничены десятью (10) устройствами. Больше никаких задач встроенные функции управления трафиком не выполняют. Поэтому, чтобы их использовать, необходимо понимать, как работает HTB и управление трафиком в Linux, и как работают метки пакетов Netfilter. За дополнительной информацией обратитесь к ссылкам, приведенным в начале этого документа. Для задания пропускной способности (как устройств, так и классов) используйте kbit или kbps (для килоБАЙТ в секунду) БЕЗ пробела между числом и единицей измерения (то есть 100kbit НО НЕ 100 kbit). Можно также использовать mbit, mbps или число (означающее байты), но поддерживаются только целые числа (0.5 использовать нельзя). Для того чтобы правильно настроить устройства, необходимо выяснить фактическую пропускную способность канала в обоих направлениях. Это особенно важно для соединений DSL или любых других, для которых пропускная способность канала не гарантирована. Не верьте числам, которые называет провайдер, но сами измерьте реальную скорость канала. В этом могут помочь различные утилиты в сети, попробуйте поискать "dsl speed test" в google (для Германии можно использовать arcor speed check). Найдите тест поближе к себе.
/etc/shorewall/tcdevices В этом файле можно задать пропускную способность способность канала для устройств, для которых будет включено управление трафиком. Это означает, что в этом файле необходимо определить параметры для устройства, чтобы для него заработало управление трафиком. Далее описаны столбцы файла: INTERFACE - Имя интерфейса. Интерфейс может быть указан не более одного раза. Использовать псевдоним интерфейса (например, eth0:0) здесь нельзя, см. FAQ #18. Также нельзя использовать символы подстановки, например, если есть несколько интерфейсов ppp, то все их необходимо здесь перечислить. В версиях Shorewall до 3.0.8 и 3.2.0 Beta 8, устройство, имя которого указано в столбце, должно было существовать в момент запуска, перезапуска или обновления Shorewall. Начиная с версии 3.0.8 и 3.2.0 Beta 8 Shorewall может определить, существует ли устройство, и настроит его только в том случае, если оно существует. Если оно не существует, то будет показано следующее предупреждение: WARNING: Device <устройство> not found -- traffic-shaping configuration skipped IN-BANDWIDTH - Пропускная способность входящего канала для этого интерфейса. Обратите внимание, что шейпинг входящего трафика невозможен, так как пакеты уже пришли. В этом столбце можно задать максимальную скорость, разрешенную для этого интерфейса, при превышении которой пакеты будут отбрасываться. Это полезно главным образом для соединений DSL или кабельных, чтобы избежать очередей в устройствах провайдера. Если не следует отбрасывать никакие пакеты, то укажите значение, превышающее фактическую максимальную скорость канала (в Shorewall начиная с версии 3.2.6 можно также указать 0). Для того чтобы определить оптимальное значение, укажите сначала значение, которое заведомо ниже, чем измеренная скорость канала (процентов на 20). Далее, в ходе загрузки файлов, измеряйте время ответа на ping между своей системой и маршрутизатором провайдера и постепенно увеличивайте это значение. Оптимальным будет значение, при превышении которого время ответа на ping будет резко расти. OUT-BANDWIDTH - Пропускная способность исходящего канала для этого интерфейса. Это максимальная скорость, с которой может работать исходящее соединение. В терминах классов tc эта скорость называется полной (full). Превышающий эту скорость исходящий трафик будет отбрасываться. Предположим, что вы работаете с PPP по Ethernet (DSL), а интерфейс - это ppp0. Устройство имеет исходящую скорость 500 кбит и входящую - 6000 кбит #INTERFACE IN-BANDWITH OUT-BANDWIDTH ppp0 6000kbit 500kbit
/etc/shorewall/tcclasses В этом файле можно задать классы, по которым будет распределяться исходящий трафик. INTERFACE - Имя интерфейса. Должно совпадать с именем интерфейса в файле /etc/shorewall/tcdevices. MARK - метка. Должна быть целым числом от 1 до 255. Эти метки задаются в файле tcrules. Они помечают пакеты, которые тем самым будут отнесены к определенным здесь классам очередей. Одни и те же метки могут использоваться для разных интерфейсов. RATE - скорость, то есть минимальная гарантированная пропускная способность, которая должна обеспечиваться для класса, когда возрастает нагрузка на канал. Классы с более высоким приоритетом обслуживаются даже в том случае, если заданы другие классы с гарантированной пропускной способностью, но низшим приоритетом. Если сумма значений RATE для всех классов, присвоенных интерфейсу, превышает OUT-BANDWIDTH для интерфейса, то предел OUT-BANDWIDTH не будет соблюдаться. CEIL - ограничение, максимальная полоса пропускания, которая отводится для данного класса, когда канал свободен. Это полезно, если есть трафик, для которого будет выделяться полная скорость канала, если более важные службы (такие как ssh) не используются. Значение "full" означает, что максимальная пропускная способность для класса определяется значением, заданным для интерфейса. PRIORITY - позволяет указать приоритет для класса. Пакеты из класса с более высоким приоритетом (то есть меньшим значением) будут обрабатываться раньше, чем пакеты с низшим приоритетом. Здесь можно просто указать значение метки, если метки присваиваются согласно приоритетам. OPTIONS - Список параметров через запятую. Возможны следующие параметры: default - класс по умолчанию для интерфейса, к которому будет отнесен весь трафик, не отнесенный к другим классам. Необходимо указать default ровно для одного класса для интерфейса. tos-<имя-tos> - позволяет указать фильтр для заданного <имени-tos>, что в свою очередь позволяет определить значение бит Type Of Service в пакете ip, вследствие чего пакет будет отнесен к этому классу. Учтите, что этот фильтр переопределяет все заданные метки, поэтому, если задать фильтр tos для класса, то все пакеты, имеющие эту метку, войдут в этот класс независимо от того, какая у них уже есть метка. Возможные значения этого параметра: tos-minimize-delay (16) tos-maximize-throughput (8) tos-maximize-reliability (4) tos-minimize-cost (2) tos-normal-service (0) Каждая из этих опций применима только для одного класса интерфейса. tcp-ack - эта опция создает фильтр tc и класс, в который помещаются все пакеты tcp ack на этом интерфейсе, размер которых не превышает 64 байта. Это позволяет ускорить загрузку. Ограничение размера пакетов ack 64 байтами служит для того, чтобы исключить из этого класса все приложения (например, p2p), которые помечают каждый пакет как пакет ack. Этому фильтру должны соответствовать только пакеты БЕЗ дополнительной нагрузки, отсюда и ограничение размера. Пакеты большего размера будут отнесены в другие классы. Эта опция применима только для одного класса интерфейса.
/etc/shorewall/tcrules Классификатор fwmark является удобным средством для классификации пакетов при управлении трафиком. В файле /etc/shorewall/tcrules эти метки представлены в виде таблицы. Глубже познакомиться с маркировкой пакетов в Netfilter/Shorewall позволяет этот документ. Обычно метка пакета ставится в цепочке PREROUTING перед тем, как осуществляется замена адресов. При этом невозможно помечать входящие пакеты согласно их целевому адресу, если применяется SNAT или Masquerading. Тем не менее, можно осуществлять маркировку пакетов в цепочке FORWARD, если задать опцию MARK_IN_FORWARD_CHAIN в файле shorewall.conf. Далее описаны столбцы файла: MARK или CLASSIFY - MARK задает значение метки, которая присваивается пакету в случае совпадения с правилом. Она должна быть целым числом от 1 до 255. Вслед за этим значением может идти : и одно из значений: F, P или "T", которые обозначают соответственно маркировку в цепочках FORWARD, PREROUTING или POSTROUTING. Если эти дополнительные спецификаторы опущены, то цепочка, в которой осуществляется маркировка пакетов, определяется следующим образом: Если SOURCE - это $FW[:<адрес>], то правило вставляется в цепочку OUTPUT. В противном случае цепочка определяется по значению опции MARK_IN_FORWARD_CHAIN из файла shorewall.conf. Спецификатор "T" был добавлен в Shorewall версии 3.3.6 и недоступен в более ранних версиях. Обычно метка присваивается пакету. Если вслед за меткой указать ":" и "C", то метка будет применяться к соединению. "C" можно сочетать с "F", "P" или "T", чтобы указать, что соединение следует пометить в определенной цепочке (например, "CF", "CP", "CT"). Предусмотрены также следующие специальные значения: RESTORE[/маска] -- восстановить метку пакета из метки соединения, используя маску, если она указана. Ядро и iptables должны поддерживать CONNMARK. Как и ранее, можно использовать дополнительные спецификаторы :P, :F или :T. SAVE[/маска] -- сохранить метку пакета в метке соединения, используя маску, если она указана. Ядро и iptables должны поддерживать CONNMARK. Как и ранее, можно использовать дополнительные спецификаторы :P, :F или :T. CONTINUE - прекратить обработку дальнейших правил маркировки в таблице. Как и ранее, можно использовать дополнительные спецификаторы :P, :F или :T. COMMENT (Начиная с Shorewall версии 3.3.3) -- остальной текст в строке будет добавлен как комментарий в правила Netfilter, генерируемые по следующим записям. Комментарий будет выделен символам "/* ... */" в выводе команды shorewall show mangle Для того чтобы комментарий не применялся к последующим строкам, укажите COMMENT в отдельной строке. При работе с CLASSIFY ядро и iptables должны поддерживать CLASSIFY. В этом случае в столбце будет содержаться классификатор (classid) в виде <основной>:<дополнительный>, где <основной> и <дополнительный> должны быть целыми числами. Он соответствует указанию 'class' в следующих модулях управления трафиком: atm cbq dsmark pfifo_fast htb prio В версиях Shorewall до 3.2.3 правила классификации всегда помещались в цепочку POSTROUTING. Начиная с Shorewall версии 3.2.3 классификация осуществляется в цепочке POSTROUTING, кроме тех случаев, когда SOURCE содержит $FW[:<адрес>], для которых классификация осуществляется в цепочке OUTPUT. При работе со встроенными функциями управления трафиком класс <основной> - это номер устройства (первая запись в файле /etc/shorewall/tcdevices - это устройство 1, вторая - устройство 2 и т.д.), а класс <дополнительный> - это значение MARK класса, перед которой стоит число "1" (для MARK со значением 1 <дополнительный> класс - это 11, для MARK со значением 22 - <дополнительный> класс 122, и т.д.). SOURCE - источник пакета. Это может быть разделенный запятыми список имен интерфейсов, IP-адресов, MAC-адресов и/или подсетей для пакетов, маршрутизируемых по общему пути. Элементы списка могут также включать имя интерфейса, к которому прибавлено ":" и адрес (например, eth1:192.168.1.0/24). Так, все пакеты для соединений, маскируемых через eth0 с других интерфейсов, можно описать одним правилом с несколькими критериями SOURCE. Однако соединение, пакеты которого приходят на eth0 по другому пути, например, из самой системы файрвола, требуют отдельного правила. Поэтому создавайте отдельное правило с $FW для пакетов, исходящих из системы файрвола. В таком правиле столбец MARK не может содержать ":P" или ":F", поскольку маркировка пакетов, исходящих из системы файрвола, всегда осуществляется в цепочке OUTPUT. MAC-адреса необходимо предварять символом "~" и использовать "-" как разделитель. Пример: ~00-A0-C9-15-39-78 DEST - назначение пакета. Список IP-адресов и/или подсетей, разделенный запятыми. Если ядро и iptables поддерживают iprange, то можно также указывать диапазоны IP-адресов. Элементы списка могут также включать имя интерфейса, к которому прибавлено ":" и адрес (например, eth1:192.168.1.0/24). Если в столбце MARK указан спецификатор в виде <основной>:<дополнительный>, то столбец может также содержать имя интерфейса. PROTO - протокол. Должен быть указан как "tcp", "udp", "icmp", "ipp2p", "ipp2p:udp", "ipp2p:all", число или "all". Для "ipp2p" требуется поддержка ipp2p в ядре и iptables. PORT(S) - целевые порты. Список имен портов (из /etc/services), номеров портов или диапазонов портов, разделенный запятыми. Если протокол - это "icmp", то столбец считается целевым типом icmp. Если протокол - это ipp2p, то столбец интерпретируется как опция ipp2p без начального "--" (например, "bit" для bit-torrent). Если PORT не указан, предполагается "ipp2p". Этот поле игнорируется, если PROTOCOL = all, но должно быть указано, если задано любое из последующих полей. В этом случае рекомендуется указывать в этом поле "-" CLIENT PORT(S) - необязательные порты, применяемые клиентом. Если они не указаны, то допускается любой целевой порт. Задается как список, разделенный запятыми, имен портов, номеров портов или диапазонов портов. USER/GROUP (Начиная с Shorewall версии 1.4.10) - Необязательный параметр имени пользователя или группы. Он может указываться, только если SOURCE - это сама система файрвола. Если значение поля задано, то правило применяется только в том случае, если программа, создавшая пакет, работает от имени указанного пользователя и/или группы. Возможные значения: [!][<имя пользователя или номер>]:[<имя группы или номер>][+<имя программы>] Двоеточие указывать необязательно, если задано только имя пользователя. Примеры: joe # программа должна выполняться пользователем joe :kids # программа выполняется участниками группы 'kids' !:kids # программа выполняется участниками группы 'kids' +upnpd # программа upnpd (эта функция была удалена из Netfilter в версии ядра 2.6.14). TEST - задает тест для проверки существующей метки пакета или соединения. Правило будет совпадать только в том случае, если тест возвращает true. Тесты имеют следующий формат: [!]<значение>[/<маска>][:C] Здесь: ! Обратное соответствие (не равно) <значение> Значение метки соединения или пакета. <маска> Маска, применяемая к метке перед сравнением :C обозначает метку соединения. Если она не указана, то сравнивается метка пакета. LENGTH - длина пакета (необязательный параметр, начиная с Shorewall версии 3.2.0). Если указано это значение, то сравнивается длина пакета с указанным значением или диапазоном значений. Диапазон задается в виде <мин>:<макс>, где можно опустить или <мин>, или <макс>, но не оба эти параметра. Если опущен <мин>, то он считается равным 0, если опущен <макс>, то совпадающим будет любой пакет, длина которого не меньше <мин>. Для этой опции необходима поддержка сравнения длины в iptables. Если значение не указано или задано как "-", то сравнение длины не выполняется. Примеры: 1024, 64:1500, :100 TOS - тип обслуживания (необязательный параметр, начиная с Shorewall версии 3.2.0 Beta 6). Стандартное имя или число.
Minimize-Delay (16) Maximize-Throughput (8) Maximize-Reliability (4) Minimize-Cost (2) Normal-Service (0)
Все пакеты, приходящие на eth1, должны иметь метку 1. Все пакеты, приходящие на eth2 и eth3, должны иметь метку 2. Все пакеты, созданные в системе файрвола, должны иметь метку 3. #MARK SOURCE DESTINATION PROTOCOL PORT(S) 1 eth1 0.0.0.0/0 all 2 eth2 0.0.0.0/0 all 2 eth3 0.0.0.0/0 all 3 $FW 0.0.0.0/0 all Все пакеты GRE (протокол 47), не созданные в системе файрвола и имеющие целевой адрес 155.186.235.151, должны иметь метку 12. #MARK SOURCE DESTINATION PROTOCOL PORT(S) 12 0.0.0.0/0 155.182.235.151 47 Все пакеты SSH, приходящие с 192.168.1.0/24 и предназначенные для 155.186.235.151, должны иметь метку 22. #MARK SOURCE DESTINATION PROTOCOL PORT(S) 22 192.168.1.0/24 155.182.235.151 tcp 22 Все пакеты SSH, проходящие через первое устройство в файле /etc/shorewall/tcdevices, должны быть отнесены в класс с меткой 10. #MARK SOURCE DESTINATION PROTOCOL PORT(S) CLIENT # PORT(S) 1:110 0.0.0.0/0 0.0.0.0/0 tcp 22 1:110 0.0.0.0/0 0.0.0.0/0 tcp - 22 Все пакеты echo ICMP должны иметь метку 1. Весь трафик протоколов p2p должен иметь метку 4. Это чуть более сложный случай. Поскольку модуль ipp2p не в состоянии распознать все пакеты в соединении как пакеты P2P, то все соединение помечается как P2P, если совпадение найдено хотя бы для одного пакета. Предполагается, что метка пакета/соединения 0 означает неклассифицированные пакеты. #MARK SOURCE DESTINATION PROTOCOL PORT(S) CLIENT USER/ TEST # PORT(S) GROUP 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request 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 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 Последние четыре правила означают следующее:
"Если пакет не был классифицирован (метка пакета 0), то скопировать метку соединения в метку пакета. Если метка пакета уже задана, то никаких действий более не требуется. Если пакет относится к типу P2P, то задать метку пакета 4. Если метка пакета задана, то сохранить ее в качестве метки соединения."
Устройства ppp Если подключение к провайдеру выполняется через ppp/pppoe/pppoa, и вы используете управление трафиком, то необходимо перезапустить управление трафиком shorewall. Причина этого состоит в том, что если соединение ppp перезапускается (обычно это происходит как минимум раз в день), то все фильтры и qdisc tc, связанные с этим интерфейсом, будут удалены. Самым простым решением будет перезапуск shorewall при повторном установлении соединения. Для этого добавьте в сценарий /etc/ppp/ip-up.d следующую строку. #! /bin/sh /sbin/shorewall refresh
Рабочие примеры
Конфигурация для замены Wondershaper Встроенные функции управления трафиком позволяют полностью заменить сценарий wondershaper. Примеры файлов конфигурации приведены по адресу "http://www1.shorewall.net/pub/shorewall/Samples/tc4shorewall/. Обратите внимание, что эти примеры необходимо настроить, чтобы они работали в вашей среде. В них предполагается, что интерфейс соединения с провайдером - это ppp0 (для DSL), и для другого типа соединения его необходимо изменить. Также требуется изменить параметры в файле tcdevices.wondershaper, чтобы они отвечали фактической скорости канала. Ниже приведены соответствующие строки из файлов конфигурации. В итоге получается точная замена того, что должен делать wondershaper. Но вы можете и вносить улучшения...
Файл tcdevices #INTERFACE IN-BANDWITH OUT-BANDWIDTH ppp0 5000kbit 500kbit
Файл tcclasses #INTERFACE MARK RATE CEIL PRIORITY OPTIONS ppp0 1 full full 1 tcp-ack,tos-minimize-delay ppp0 2 9*full/10 9*full/10 2 default ppp0 3 8*full/10 8*full/10 2
Файл tcrules #MARK SOURCE DEST PROTO PORT(S) CLIENT USER # PORT(S) 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 # метка для трафика с низким приоритетом: # mldonkey 3 0.0.0.0/0 0.0.0.0/0 udp - 4666 Wondershaper позволяет определить набор хостов и/или портов, которым присваивается низкий приоритет. Для этого в tcrules этим хостам нужно присвоить метку 3 (как это делается в примерах файлов конфигурации).
Присвоение низкого приоритета хостам Допустим, что в сценарии wondershaper были следующие параметры (только в качестве примера): # Низкий приоритет для исходящего трафика - можно оставить пустым, # чтобы применять сетевые маски для низкого приоритета NOPRIOHOSTSRC="192.168.1.128/25 192.168.3.28" # Низкий приоритет - маска для назначения NOPRIOHOSTDST=60.0.0.0/24 # Низкий приоритет - порты источника NOPRIOPORTSRC="6662 6663" # Низкий приоритет - порты назначения NOPRIOPORTDST="6662 6663" Эти параметры будут отражены следующим образом в файле tcrules: 3 192.168.1.128/25 0.0.0.0/0 all 3 192.168.3.28 0.0.0.0/0 all 3 0.0.0.0/0 60.0.0.0/24 all 3 0.0.0.0/0 0.0.0.0/0 udp 6662,6663 3 0.0.0.0/0 0.0.0.0/0 udp - 6662,6663 3 0.0.0.0/0 0.0.0.0/0 tcp 6662,6663 3 0.0.0.0/0 0.0.0.0/0 tcp - 6662,6663
Простая конфигурация Ниже приведен простой пример для общего подключения к Интернет с разных компьютеров. Фактически здесь настроен шейпинг для двух хостов с IP-адресами 192.168.2.23 и 192.168.2.42
Файл tcdevices #INTERFACE IN-BANDWITH OUT-BANDWIDTH ppp0 6000kbit 700kbit Канал имеет входящие 6 мбит и исходящие 700 кбит.
Файл tcclasses #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 Добавляется класс для пакетов tcp ack с высоким приоритетом, чтобы ускорить загрузку. Следующие два класса совместно используют большую часть пропускной способности канала для двух хостов, и если соединение свободно, то всю пропускную способность. Так как хосты считаются равноправными, они имеют одинаковый приоритет. Последний класс предназначен для остального трафика.
Файл tcrules #MARK SOURCE DEST PROTO PORT(S) CLIENT USER # PORT(S) 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 Пакеты ping icmp и ответы помечаются отдельно, как относящиеся к интерактивному классу. Для них метка ставится для обоих хостов.
Замечания для пользователей Xen Если управление трафиком включено в dom0, но исходящий трафик при этом шейпится неправильно, то причиной этого может быть "выгрузка контрольных сумм" (checksum offloading) в ваших domU. Просмотрите вывод команды "shorewall show tc". Ниже приведен пример: 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 В приведенном примере легко обнаружить две проблемы: Скорость (299288) заметно превышает установленный предел (230000). Сообщается о большом числе огромных пакетов (90174). Эта неполадка устраняется выключением "checksum offloading" в domU с помощью программы ethtool. За инструкциями обратитесь к статье по Xen.
Применение собственных сценариев tc
Замена встроенного файла tcstart Если вы предпочитаете сами создать файл запуска tc, просто поместите его в /etc/shorewall/tcstart. В сценарии tcstart вместо вызова программы tc используйте функцию run_tc из Shorewall, чтобы при ошибке tc остановить файрвол. Задайте TC_ENABLED=Yes и CLEAR_TC=Yes Укажите сценарий /etc/shorewall/tcstart с правилами управления трафиком. Укажите также необязательный сценарий /etc/shorewall/tcclear для остановки управления трафиком. Обычно это не требуется. Если сценарий tcstart применяет классификатор fwmark, то можно помечать пакеты, используя записи из /etc/shorewall/tcrules.
Управление трафиком, внешнее по отношению к Shorewall Для того чтобы запустить управление трафиком при поднятии сетевых интерфейсов, необходимо запустить сценарий управления трафиком именно в этот момент. Это зависит от применяемого дистрибутива и здесь не описывается. После этого сделайте следующее: Задайте TC_ENABLED=No и CLEAR_TC=No Если сценарий применяет классификатор fwmark, то можно помечать пакеты, используя записи из /etc/shorewall/tcrules.
Инструменты тестирования Как минимум один пользователь Shorewall посчитал полезными следующие инструменты: http://e2epi.internet2.edu/network-performance-toolkit.html
shorewall-docs-xml-4.5.21/FAQ_fr.xml0000644000175000017500000032445712222401136017053 0ustar teastepteastep
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-4.5.21/XenMyWay.xml0000644000175000017500000012275512222401136017473 0ustar teastepteastep
Xen and the Art of Consolidation Tom Eastep 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. 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.
Xen Network Environment Xen is a paravirtualization tool that allows you to run multiple virtual machines on one physical machine. It is available on a wide number of platforms and is included in recent SUSE distributions. Xen refers to the virtual machines as Domains. Domains are numbered with the first domain being domain 0, the second domain 1, and so on. Domain 0 (Dom0) is special because that is the domain created when the machine is booted. Additional domains (called DomU's) are created using the xm create command from within Domain 0. Additional domains can also be created automatically at boot time by using the xendomains service. Xen virtualizes a network interface named eth0 This assumes the default Xen configuration created by xend and assumes that the host system has a single Ethernet interface named eth0. in each domain. In Dom0, Xen also creates a bridge (xenbr0) and a number of virtual interfaces as shown in the following diagram. I use the term Extended Dom0 to distinguish the bridge and virtual interfaces from Dom0 itself. That distinction is important when we try to apply Shorewall in this environment. The bridge has a number of ports: peth0 — This is the port that connects to the physical network interface in your system. vif0.0 — This is the bridge port that is used by traffic to/from Domain 0. vifX.0 — This is the bridge port that is used by traffic to/from Domain X.
Before Xen Prior to adopting Xen, I had a home office crowded with 5 systems, three monitors a scanner and a printer. The systems were: Firewall Public Server in a DMZ (mail) Private Server (wookie) My personal Linux Desktop (ursa) My work system (docked laptop running Windows XP). The result was a very crowded and noisy room.
After Xen Xen has allowed me to reduce the noise and clutter considerably. I now have three systems with two monitors. I've also replaced the individual printer and scanner with a Multifunction FAX/Scanner/Printer. The systems now include: Combination Firewall/Public Server/Private Server/Wireless Gateway using Xen (created by building out my Linux desktop system). My work system. My Linux desktop (wookie, which is actually the old public server box) Most of the Linux systems run SUSE 10.1; my personal Linux desktop system and our Linux Laptop run Ubuntu "Dapper Drake". The configuration described below uses a bridged Xen Networking configuration; if you want to see how to accomplish a similar configuration using a Routed Xen configuration then please see this article. I am now using the routed configuration because it results in one fewer domains to administer. Here is a high-level diagram of our network. As shown in this diagram, the Xen system has three physical network interfaces. These are: eth0 -- connected to the switch in my office. That switch is cabled to a second switch in my wife's office where my wife has her desktop and networked printer (I sure wish that there had been wireless back when I strung that CAT-5 cable halfway across the house). eth1 -- connected to our DSL "Modem". eth2 -- connected to a Wireless Access Point (WAP) that interfaces to our wireless network. There are three Xen domains. Dom0 (DNS name ursa.shorewall.net) is used as a local file server (NFS and Samba). The first DomU (Dom name firewall, DNS name gateway.shorewall.net) is used as our main firewall and wireless gateway. The second DomU (Dom name lists, DNS name lists.shorewall.net) is used as a public Web/FTP/Mail/DNS server. Shorewall runs in Dom0 and in the firewall domain. As the developer of Shorewall, I have enough experience to be very comfortable with Linux networking and Shorewall/iptables. I arrived at this configuration after a fair amount of trial and error experimentation. If you are a Linux networking novice, I recommend that you do not attempt a configuration like this one for your first Shorewall installation. You are very likely to frustrate both yourself and the Shorewall support team. Rather I suggest that you start with something simple like a standalone installation in a domU; once you are comfortable with that then you will be ready to try something more substantial. As Paul Gear says: Shorewall might make iptables easy, but it doesn't make understanding fundamental networking principles, traffic shaping, or multi-ISP routing any easier. The same goes for Xen networking.
Domain Configuration Below are the relevant configuration files for the three domains. I use partitions on my hard drives for DomU storage devices.
/boot/grub/menu.lst — here is the entry that boots Xen in Dom0. title XEN root (hd0,1) kernel /boot/xen.gz dom0_mem=458752 sched=bvt module /boot/vmlinuz-xen root=/dev/hda2 vga=0x31a selinux=0 resume=/dev/hda1 splash=silent showopts module /boot/initrd-xen /etc/modprobe.conf.local eth1 (PCI 00:09.0) and eth2 (PCI 00:0a.0) are delegated to the firewall DomU where they become eth3 and eth4 respectively. The SUSE 10.1 Xen kernel compiles pciback as a module so the instructions for PCI delegation in the Xen Users Manual can't be followed directly (see http://wiki.xensource.com/xenwiki/Assign_hardware_to_DomU_with_PCIBack_as_module). options pciback hide=(00:09.0)(00:0a.0) install tulip /sbin/modprobe pciback ; /sbin/modprobe --first-time --ignore-install tulip options netloop nloopbacks=1 /etc/xen/auto/01-firewall — configuration file for the firewall domain # -*- mode: python; -*- # configuration name: name = "firewall" # usable ram: memory = 384 # kernel and initrd: kernel = "/xen2/vmlinuz-xen" ramdisk = "/xen2/initrd-xen" # boot device: root = "/dev/hdb2" # boot to run level: extra = "3" # network interface: vif = [ 'mac=aa:cc:00:00:00:02, bridge=xenbr0', 'mac=aa:cc:00:00:00:03, bridge=xenbr1' ] # Interfaces delegated from Dom0 pci=[ '00:09.0' , '00:0a.0' ] # storage devices: disk = [ 'phy:hdb2,hdb2,w' ] /etc/xen/auto/02-lists — configuration file for the lists domain # -*- mode: python; -*- # configuration name: name = "lists" # usable ram: memory = 512 # kernel and initrd: kernel = "/xen2/vmlinuz-xen" ramdisk = "/xen2/initrd-xen" # boot device: root = "/dev/hda3" # boot to run level: extra = "3" # network interface: vif = [ 'mac=aa:cc:00:00:00:01, bridge=xenbr1' ] hostname = name # storage devices: disk = [ 'phy:hda3,hda3,w' ]
With all three Xen domains up and running, the system looks as shown in the following diagram. The zones correspond to the Shorewall zones in the firewall DomU configuration. If you want to run a simple NAT gateway in a Xen DomU, just omit the second bridge (xenbr1), the second delegated interface, and the second DomU from the above configuration. You can then install the normal Shorewall two-interface sample configuration in the DomU. Under some circumstances, UDP and/or TCP communication from a domU won't work for no obvious reason. That happened with the lists domain in my setup. Looking at the IP traffic with tcpdump -nvvi eth1 in the firewall domU showed that UDP packets from the lists domU had incorrect checksums. That problem was corrected by arranging for the following command to be executed in the lists domain when its eth0 device was brought up: ethtool -K eth0 tx off Under SUSE 10.1, I placed the following in /etc/sysconfig/network/if-up.d/resettx (that file is executable): #!/bin/sh if [ $2 = eth0 ]; then ethtool -K eth0 tx off echo "TX Checksum reset on eth0" fi Under other distributions, the technique will vary. For example, under Debian or Ubuntu, you can just add a 'post-up' entry to /etc/network/interfaces as shown here: iface eth0 inet static address 206.124.146.177 netmask 255.255.255.0 post-up ethtool -K eth0 tx off Update. Under SUSE 10.2, communication from a domU works okay without running ethtool but traffic shaping in dom0 doesn't work! So it's a good idea to run it just to be safe. SUSE 10.1 includes Xen 3.0.2 which supports PCI delegation. The network interfaces that connect to the net and wifi zones are delegated to the firewall DomU. When Shorewall starts during bootup of Dom0, it creates the two bridges using this /etc/shorewall/init extension script:
for bridge in xenbr0 xenbr1; do if [ -z "$(/sbin/brctl show 2> /dev/null | fgrep $bridge)" ]; then /sbin/brctl addbr $bridge /sbin/ip link set dev $bridge up fi done
Dom0 Configuration The goals for the Shorewall configuration in Dom0 are as follows: Allow traffic to flow unrestricted through the two bridges. This is done by configuring the hosts connected to each bridge as a separate zone and relying on Shorewall's implicit intra-zone ACCEPT policy to permit traffic through the bridge. Ensure that there is no stray traffic between the zones. This is a "belt+suspenders" measure since there should be no routing between the bridges (because they don't have IP addresses). The configuration is a simple one:
/etc/shorewall/zones: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall loc ipv4 dmz ipv4 #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE /etc/shorewall/policy (Note the unusual use of an ACCEPT all->all policy): #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL dmz all REJECT info all dmz REJECT info all all ACCEPT #LAST LINE -- DO NOT REMOVE /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS loc xenbr0 192.168.1.255 dhcp,routeback dmz xenbr1 - routeback #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT PORT(S) DEST LIMIT GROUP #SECTION ESTABLISHED #SECTION RELATED SECTION NEW #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
Firewall DomU Configuration In the firewall DomU, I run a conventional three-interface firewall with Proxy ARP DMZ -- it is very similar to the firewall described in the Shorewall Setup Guide with the exception that I've added a fourth interface for our wireless network. The firewall runs a routed OpenVPN server to provide road warrior access for our two laptops and a bridged OpenVPN server for the wireless network in our home. Here is the firewall's view of the network: The two laptops can be directly attached to the LAN as shown above or they can be attached wirelessly -- their IP addresses are the same in either case; when they are directly attached, the IP address is assigned by the DHCP server running in Dom0 and when they are attached wirelessly, the IP address is assigned by OpenVPN. The Shorewall configuration files are shown below. All routing and secondary IP addresses are handled in the SUSE network configuration.
/etc/shorewall/shorewall.conf: STARTUP_ENABLED=Yes VERBOSITY=0 LOGFILE=/var/log/firewall LOGFORMAT="Shorewall:%s:%s:" LOGTAGONLY=No LOGRATE= LOGBURST= LOGALLNEW= BLACKLIST_LOGLEVEL= MACLIST_LOG_LEVEL=$LOG TCP_FLAGS_LOG_LEVEL=$LOG SMURF_LOG_LEVEL=$LOG LOG_MARTIANS=No IPTABLES=/usr/sbin/iptables PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin SHOREWALL_SHELL=/bin/bash SUBSYSLOCK= MODULESDIR= CONFIG_PATH=/etc/shorewall:/usr/share/shorewall RESTOREFILE=standard IPSECFILE=zones IP_FORWARDING=On ADD_IP_ALIASES=No ADD_SNAT_ALIASES=No RETAIN_ALIASES=No TC_ENABLED=Internal CLEAR_TC=Yes MARK_IN_FORWARD_CHAIN=Yes CLAMPMSS=Yes ROUTE_FILTER=No DETECT_DNAT_IPADDRS=Yes MUTEX_TIMEOUT=60 ADMINISABSENTMINDED=Yes BLACKLISTNEWONLY=Yes DELAYBLACKLISTLOAD=No MODULE_SUFFIX= DISABLE_IPV6=Yes BRIDGING=No DYNAMIC_ZONES=No PKTTYPE=No MACLIST_TTL=60 SAVE_IPSETS=No MAPOLDACTIONS=No FASTACCEPT=Yes BLACKLIST_DISPOSITION=DROP MACLIST_TABLE=mangle MACLIST_DISPOSITION=DROP TCP_FLAGS_DISPOSITION=DROP /etc/shorewall/zones: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 #Internet loc ipv4 #Local wired Zone dmz ipv4 #DMZ vpn ipv4 #Open VPN clients wifi ipv4 #Local Wireless Zone #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE /etc/shorewall/policy: #SOURCE DEST POLICY LOG LIMIT:BURST # LEVEL $FW $FW ACCEPT $FW net ACCEPT loc net ACCEPT $FW vpn ACCEPT vpn net ACCEPT vpn loc ACCEPT loc vpn ACCEPT $FW loc ACCEPT wifi all REJECT $LOG loc $FW REJECT $LOG net $FW DROP $LOG 1/sec:2 net loc DROP $LOG 2/sec:4 net dmz DROP $LOG 8/sec:30 net vpn DROP $LOG all all REJECT $LOG #LAST LINE -- DO NOT REMOVE /etc/shorewall/params (edited): MIRRORS=<comma-separated list of Shorewall mirrors> NTPSERVERS=<comma-separated list of NTP servers I sync with> POPSERVERS=<comma-separated list of server IP addresses> LOG=info INT_IF=eth0 DMZ_IF=eth1 EXT_IF=eth3 WIFI_IF=eth4 OMAK=<IP address at our second home> #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE /etc/shorewall/init: echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net $EXT_IF 206.124.146.255 dhcp,logmartians,blacklist,tcpflags,nosmurfs dmz $DMZ_IF 192.168.0.255 logmartians loc $INT_IF 192.168.1.255 dhcp,routeback,logmartians wifi $WIFI_IF 192.168.3.255 dhcp,maclist vpn tun+ - #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/nat: #EXTERNAL INTERFACE INTERNAL ALL LOCAL # INTERFACES 206.124.146.178 $EXT_IF 192.168.1.3 No No #Wookie 206.124.146.180 $EXT_IF 192.168.1.6 No No #Work LapTop #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE /etc/shorewall/masq (Note the cute trick here and in the following proxyarp file that allows me to access the DSL "Modem" using its default IP address (192.168.1.1)). The leading "+" is required to place the rule before the SNAT rules generated by entries in /etc/shorewall/nat above. #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC +$EXT_IF:192.168.1.1 0.0.0.0/0 192.168.1.254 $EXT_IF 192.168.0.0/22 206.124.146.179 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE /etc/shorewall/proxyarp: #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 192.168.1.1 $EXT_IF $INT_IF yes 206.124.146.177 $DMZ_IF $EXT_IF yes #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/tunnels: #TYPE ZONE GATEWAY GATEWAY # ZONE openvpnserver:udp net 0.0.0.0/0 #Routed server for RoadWarrior access openvpnserver:udp wifi 192.168.3.0/24 #Home wireless network server #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/actions: #ACTION Mirrors # Accept traffic from Shorewall Mirrors #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE /etc/shorewall/action.Mirrors: #TARGET SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE # PORT PORT(S) DEST LIMIT ACCEPT $MIRRORS #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/rules: SECTION NEW ############################################################################################################################################################################### #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ # PORT PORT(S) DEST LIMIT GROUP ############################################################################################################################################################################### REJECT:$LOG loc net tcp 25 REJECT:$LOG loc net udp 1025:1031 # # Stop NETBIOS crap # REJECT loc net tcp 137,445 REJECT loc net udp 137:139 # # 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 ############################################################################################################################################################################### # Local Network to Firewall # DROP loc:!192.168.0.0/22 fw # Silently drop traffic with an HP source IP from my XP box ACCEPT loc fw tcp 22 ACCEPT loc fw tcp time,631,8080 ACCEPT loc fw udp 161,ntp,631 ACCEPT loc:192.168.1.5 fw udp 111 DROP loc fw tcp 3185 #SUSE Meta pppd Ping(ACCEPT) loc fw REDIRECT loc 3128 tcp 80 - !206.124.146.177 ############################################################################################################################################################################### # Road Warriors to Firewall # ACCEPT vpn fw tcp ssh,time,631,8080 ACCEPT vpn fw udp 161,ntp,631 Ping(ACCEPT) vpn fw ############################################################################################################################################################################### # Road Warriors to DMZ # ACCEPT vpn dmz udp domain ACCEPT vpn dmz tcp www,smtp,smtps,domain,ssh,imap,https,imaps,ftp,10023,pop3 - Ping(ACCEPT) vpn dmz ############################################################################################################################################################################### # Local network to DMZ # ACCEPT loc dmz udp domain ACCEPT loc dmz tcp ssh,smtps,www,ftp,imaps,domain,https - ACCEPT loc dmz tcp smtp Trcrt(ACCEPT) loc dmz ############################################################################################################################################################################### # Internet to ALL -- drop NewNotSyn packets # dropNotSyn net fw tcp dropNotSyn net loc tcp dropNotSyn net dmz tcp ############################################################################################################################################################################### # Internet to DMZ # ACCEPT net dmz udp domain ACCEPT net dmz tcp smtps,www,ftp,imaps,domain,https - ACCEPT net dmz tcp smtp - 206.124.146.177,206.124.146.178 ACCEPT net dmz udp 33434:33454 Mirrors net dmz tcp rsync Limit:$LOG:SSHA,3,60\ net dmz tcp 22 Trcrt(ACCEPT) net dmz ############################################################################################################################################################################## # # Net to Local # # When I'm "on the road", the following two rules allow me VPN access back home using PPTP. # DNAT net loc:192.168.1.4 tcp 1729 DNAT net loc:192.168.1.4 gre # # Roadwarrior access to Wookie # ACCEPT net:$OMAK loc tcp 22 Limit:$LOG:SSHA,3,60\ net loc tcp 22 # # ICQ # ACCEPT net loc:192.168.1.3 tcp 113,4000:4100 # # Bittorrent # ACCEPT net loc:192.168.1.3 tcp 6881:6889,6969 ACCEPT net loc:192.168.1.3 udp 6881:6889,6969 # # Skype # ACCEPT net loc:192.168.1.6 tcp 1194 # # Traceroute # Trcrt(ACCEPT) net loc:192.168.1.3 # # Silently Handle common probes # REJECT net loc tcp www,ftp,https DROP net loc icmp 8 ############################################################################################################################################################################### # DMZ to Internet # ACCEPT dmz net udp domain,ntp ACCEPT dmz net tcp echo,ftp,ssh,smtp,whois,domain,www,81,https,cvspserver,2702,2703,8080 ACCEPT dmz net:$POPSERVERS tcp pop3 Ping(ACCEPT) dmz net # # Some FTP clients seem prone to sending the PORT command split over two packets. This prevents the FTP connection tracking # code from processing the command and setting up the proper expectation. The following rule allows active FTP to work in these cases # but logs the connection so I can keep an eye on this potential security hole. # ACCEPT:$LOG dmz net tcp 1024: 20 ############################################################################################################################################################################### # Local to DMZ # ACCEPT loc dmz udp domain,xdmcp ACCEPT loc dmz tcp www,smtp,smtps,domain,ssh,imap,rsync,https,imaps,ftp,10023,pop3,3128 Trcrt(ACCEPT) loc dmz ############################################################################################################################################################################### # DMZ to Local # ACCEPT dmz loc:192.168.1.5 udp 123 ACCEPT dmz loc:192.168.1.5 tcp 21 Ping(ACCEPT) dmz loc ############################################################################################################################################################################### # DMZ to Firewall -- ntp & snmp, Silently reject Auth # ACCEPT dmz fw tcp 161,ssh ACCEPT dmz fw udp 161 REJECT dmz fw tcp auth Ping(ACCEPT) dmz fw ############################################################################################################################################################################### # Internet to Firewall # REJECT net fw tcp www,ftp,https DROP net fw icmp 8 ACCEPT net fw udp 33434:33454 ACCEPT net:$OMAK fw udp ntp ACCEPT net fw tcp auth ACCEPT net:$OMAK fw tcp 22 Limit:$LOG:SSHA,3,60\ net fw tcp 22 Trcrt(ACCEPT) net fw ############################################################################################################################################################################### # Firewall to DMZ # ACCEPT fw dmz tcp domain,www,ftp,ssh,smtp,https,993,465 ACCEPT fw dmz udp domain REJECT fw dmz udp 137:139 Ping(ACCEPT) fw dmz ############################################################################################################################################################################## # Avoid logging Freenode.net probes # DROP net:82.96.96.3 all #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/tcdevices #INTERFACE IN-BANDWITH OUT-BANDWIDTH $EXT_IF 1300kbit 384kbit #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/tcclasses#INTERFACE MARK RATE CEIL PRIORITY OPTIONS $EXT_IF 10 5*full/10 full 1 tcp-ack,tos-minimize-delay $EXT_IF 20 3*full/10 9*full/10 2 default $EXT_IF 30 2*full/10 6*full/10 3 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/tcrules#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST # PORT(S) 1:110 192.168.0.0/22 $EXT_IF #Our internal nets get priority #over the server 1:130 206.124.146.177 $EXT_IF tcp - 873 #Throttle rsync traffic to the #Shorewall Mirrors. #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
The tap0 device used by the bridged OpenVPN server is bridged to eth0 using a SUSE-specific SysV init script:
#!/bin/sh # # The Shoreline Firewall (Shorewall) Packet Filtering Firewall - V3.0 # # This program is under GPL [http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt] # # (c) 1999,2000,2001,2002,2003,2004,2005 - Tom Eastep (teastep@shorewall.net) # # On most distributions, this file should be called /etc/init.d/shorewall. # # Complete documentation is available at http://shorewall.net # # This program is free software; you can redistribute it and/or modify # it under the terms of Version 2 of the GNU General Public License # as published by the Free Software Foundation. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. # # If an error occurs while starting or restarting the firewall, the # firewall is automatically stopped. # # Commands are: # # bridge start Starts the bridge # bridge restart Restarts the bridge # bridge reload Restarts the bridge # bridge stop Stops the bridge # bridge status Displays bridge status # # chkconfig: 2345 4 99 # description: Packet filtering firewall ### BEGIN INIT INFO # Provides: bridge # Required-Start: boot.udev # Required-Stop: # Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Description: starts and stops the bridge ### END INIT INFO ################################################################################ # Interfaces to be bridged -- may be listed by device name or by MAC # INTERFACES="eth0" # # Tap Devices # TAPS="tap0" ################################################################################ # Give Usage Information # ################################################################################ usage() { echo "Usage: $0 start|stop|reload|restart|status" exit 1 } ################################################################################# # Find the interface with the passed MAC address ################################################################################# find_interface_by_mac() { local mac mac=$1 local first local second local rest local dev /sbin/ip link ls | while read first second rest; do case $first in *:) dev=$second ;; *) if [ "$second" = $mac ]; then echo ${dev%:} return fi esac done } ################################################################################ # Convert MAC addresses to interface names ################################################################################ get_interfaces() { local interfaces interfaces= local interface for interface in $INTERFACES; do case $interface in *:*:*) interface=$(find_interface_by_mac $interface) [ -n "$interface" ] || echo "WARNING: Can't find an interface with MAC address $mac" ;; esac interfaces="$interfaces $interface" done INTERFACES="$interfaces" } ################################################################################ # Start the Bridge ################################################################################ do_start() { local interface get_interfaces for interface in $TAPS; do /usr/sbin/openvpn --mktun --dev $interface done /sbin/brctl addbr br0 for interface in $INTERFACES $TAPS; do /sbin/ip link set $interface up /sbin/brctl addif br0 $interface done } ################################################################################ # Stop the Bridge ################################################################################ do_stop() { local interface get_interfaces for interface in $INTERFACES $TAPS; do /sbin/brctl delif br0 $interface /sbin/ip link set $interface down done /sbin/ip link set br0 down /sbin/brctl delbr br0 for interface in $TAPS; do /usr/sbin/openvpn --rmtun --dev $interface done } ################################################################################ # E X E C U T I O N B E G I N S H E R E # ################################################################################ command="$1" case "$command" in start) do_start ;; stop) do_stop ;; restart|reload) do_stop do_start ;; status) /sbin/brctl show ;; *) usage ;; esac
shorewall-docs-xml-4.5.21/Vserver.xml0000644000175000017500000001776212222401136017407 0ustar teastepteastep
Shorewall and Linux-vserver Tom Eastep 2010 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 Formal support for Linux-vserver was added in Shorewall 4.4.11 Beta2. The centerpiece of that support is the vserver zone type. Vserver zones have the following characteristics: They are defined on the Linux-vserver host. The $FW zone is their implicit parent. Their contents must be defined using the shorewall-hosts (5) file. The ipsec option may not be specified. They may not appear in the ZONE column of the shorewall-interfaces (5) file. Note that you don't need to run Vservers to use vserver zones; they may also be used to create a firewall sub-zone for each aliased interface. If you use these zones, keep in mind that Linux-vserver implements a very weak form of network virtualization: From a networking point of view, vservers live on the host system. So if you don't use care, Vserver traffic to/from zone z will be controlled by the fw->z and z->fw rules and policies rather than by vserver->z and z->vserver rules and policies. Outgoing connections from a vserver will not use the Vserver's address as the SOURCE IP address unless you configure applications running in the Vserver properly. This is especially true for IPv6 applications. Such connections will appear to come from the $FW zone rather than the intended Vserver zone. While you can define the vservers to be associated with the network interface where their IP addresses are added at vserver startup time, Shorewall internally associates all vservers with the loopback interface (lo). Here's an example of how that association can show up: gateway:~# shorewall show zones Shorewall 4.4.11-Beta2 Zones at gateway - Fri Jul 2 12:26:30 PDT 2010 fw (firewall) drct (ipv4) eth4:+drct_eth4 loc (ipv4) eth4:0.0.0.0/0 net (ipv4) eth1:0.0.0.0/0 vpn (ipv4) tun+:0.0.0.0/0 dmz (vserver) lo:70.90.191.124/31 gateway:~#
Vserver Zones This is a diagram of the network configuration here at Shorewall.net during the summer of 2010: I created a zone for the vservers as follows: /etc/shorewall/zones: #ZONE TYPE OPTIONS ... fw firewall loc ip #Local Zone drct:loc ipv4 #Direct internet access net ipv4 #Internet vpn ipv4 #OpenVPN clients dmz vserver #Vservers /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net eth1 detect dhcp,optional,routefilter=0,logmartians,proxyarp=0,nosmurfs,upnp ... /etc/shorewall/hosts: #ZONE HOST(S) OPTIONS drct eth4:dynamic dmz eth1:70.90.191.124/31 While the IP addresses 70.90.191.124 and 70.90.191.125 are configured on eth1, the actual interface name is irrelevant so long as the interface is defined in shorewall-interfaces (5). Shorewall will consider all vserver zones to be associated with the loopback interface (lo). Once a vserver zone is defined, it can be used like any other zone type. Here is the corresponding IPv6 configuration. /etc/shorewall6/zones #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv6 loc ipv6 vpn ipv6 dmz vserver /etc/shorewall6/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net sit1 detect tcpflags,forward=1,nosmurfs,routeback ... /etc/shorewall6/hosts: #ZONE HOST(S) OPTIONS dmz sit1:[2001:470:e857:1::/64] Note that I choose to place the Vservers on sit1 (the IPv6 net interface) rather than on eth1. Again, it really doesn't matter much.
Sharing an IPv6 /64 between Vservers and a LAN I have both a /64 (2001:470:b:227::/64) and a /48 (2001:470:e857::/48) from Hurricane Electric. When I first set up my Vserver configuration, I assigned addresses from the /48 to the Vservers as shown above. Given that it is likely that when native IPv6 is available from my ISP, I will only be able to afford a single /64, in February 2011 I decided to migrate my vservers to the /64. This was possible because of Proxy NDP support in Shorewall 4.4.16 and later. The new network diagram is as shown below: This change was accompanied by the following additions to /etc/shorewall6/proxyndp: #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 2001:470:b:227::2 - eth4 Yes Yes 2001:470:b:227::3 - eth4 Yes Yes These two entries allow the firewall to respond to NDP requests for the two Vserver IPv6 addresses received on interface eth4. As part of this change, the Lists vserver (OpenSuSE 10.3 was retired in favor of Mail (Debian Squeeze).
shorewall-docs-xml-4.5.21/shorewall_setup_guide_fr.xml0000644000175000017500000034142312222401136023031 0ustar teastepteastep
Guide de configuration Shorewall Version Franaise de Shorewall Setup Guide Tom Eastep Fabien Demassieux Traduction Franaise initiale Guy Marcenac Adaptation franaise version 3.0 2002-2006 Thomas M. Eastep Fabien Demassieux 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 : Le traduction initiale a t ralise par Fabien Demassieux. J'ai assur la rvision pour l'adapter la version 3 de Shorewall. Si vous trouvez des erreurs ou des amliorations y apporter 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.
Introduction Ce guide est destin aux utilisateurs qui configurent Shorewall dans un environnement o un ensemble d'adresses IP publiques doit tre pris en compte ainsi qu' ceux qui souhaitent en savoir plus propos de Shorewall que ce que contiennent le guides pour une utilisation avec une adresse IP unique. Le champs d'application tant trs large, ce guide vous donnera des indications gnrales suivre et vous indiquera d'autres ressources si ncessaire. Shorewall a besoin que le paquetage iproute/iproute2 soit install (avec la distribution RedHat, le paquetage s'appelle iproute). Vous pouvez contrler que le paquetage est install en vrifiant la prsence 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 complte 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. Les points o des modifications s'imposent sont indiqus par . Si vous ditez vos fichiers de configuration sur un systme 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 mme manire, 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. Version Windows de dos2unix Version Linux de dos2unix
Les Concepts de Shorewall Les fichiers de configuration pour Shorewall sont situs dans le rpertoire /etc/shorewall -- pour de simples paramtrages, vous n'aurez faire qu'avec quelques-uns d'entre eux comme dcrit dans ce guide. Des squelettes de fichiers sont crs durant la procdure d'installation de Shorewall. Note aux utilisateurs de Debian 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. Au fur et mesure de la prsentation de chaque fichier, je vous suggre de jeter un oeil ceux physiquement prsents sur votre systme -- chacun des fichiers contient des instructions de configuration dtailles et des entres par dfaut. Shorewall voit le rseau o il fonctionne, comme tant compos d'un ensemble de zones. Dans ce guide nous utiliserons les zones suivantes: fw Le firewall lui-mme. net L'internet public. loc Un rseau local priv utilisant des adresses IP prives. dmz Une zone dmilitarise (DMZ) contenant les serveurs publiquement accessibles. Les Zones sont dfinies dans le fichier /etc/shorewall/zones. Le fichier /etc/shorewall/zones fourni avec la distribution est vide. Vous pouvez crer l'ensemble de zones standard dcrites au-dessus en copiant puis en collant ce qui suit dans le fichier: #ZONE TYPE OPTIONS fw firewall net ipv4 loc ipv4 dmz ipv4 Remarquez que Shorewall reconnat aussi le systme firewall comme sa propre zone - l'exemple ci-dessus suit la convention qui veut que la zone firewall soit nomme fw. Le nom de la zone firewall (fw dans l'exemple plus haut) est stock dans la variable d'environnement $FW lorsque le fichier /etc/shorewall/zones est trait. A l'exception du nom attribu la zone firewall, Shorewall n'attache aucune signification aux noms de zone. Le zones sont entirement ce que VOUS en faites. Ceci signifie que vous ne devriez pas attendre de Shorewall qu'il fasse quoi que ce soit de spcial car il s'agit de la zone internet ou car ceci est la DMZ. ditez le fichier /etc/shorewall/zones et faites-y les changements ncessaires. Les rgles qui concernent le trafic autoriser ou refuser sous exprimes en termes de Zones. Vous exprimez les politiques par dfaut entre une zone et une autre zone dans le fichier /etc/shorewall/policy. Vous dfinissez les exceptions ces politiques par dfaut dans le fichier /etc/shorewall/rules. Shorewall est construit sur les mcanismes de Netfilter, service de filtrage du noyau (kernel). Netfilter fournit une fonction de suivi de connexion qui permet une analyse d'tat des paquets (stateful inspection). Cette proprit permet aux rgles du firewall d'tre dfinies en termes de connexions plutt qu'en termes de paquets. Avec Shorewall, vous: Identifiez la zone source (client). Identifiez la zone destination (serveur). Si la politique depuis la zone du client vers la zone du serveur est ce que vous souhaitez pour cette paire client/serveur, vous n'avez rien de plus faire. Si la politique n'est pas ce que vous souhaitez, alors vous devez ajouter une rgle. Cette rgle est exprime en termes de zone client et de zone serveur. Autoriser les connexions d'un certain type depuis la zone A vers le firewall et depuis firewall vers la zone B NE SIGNIFIE PAS que ces connections sont autoriss de la zone A la zone B (autrement dit, les connexions impliquant la zone firewall ne sont pas transitives). Pour chaque connexion demandant entrer dans le firewall, la requte est en premier lieu vrifie par rapport au fichier /etc/shorewall/rules. Si aucune rgle dans ce fichier ne correspond la demande de connexion alors la premire politique dans le fichier /etc/shorewall/policy qui y correspond sera applique. S'il y a une action par dfaut dfinie pour cette politique dans /etc/shorewall/actions ou dans /usr/share/shorewall/actions.std cette action commune sera excute avant que l'action spcifie dans /etc/shorewall/rules ne soit applique. Avant Shorewall 2.2.0, le fichier /etc/shorewall/policy avait les politiques suivantes: #SOURCE ZONE DESTINATION ZONE POLICY LOG LIMIT:BURST # LEVEL fw net ACCEPT net all DROP info all all REJECT info Le fichier de politiques distribu actuellement est vide. Vous pouvez y copier et coller les entres prsentes ci-dessus comme point de dpart, puis l'adapter vos propres politiques. Les politiques prcdentes vont: Autoriser (ACCEPT) toutes les connexions de votre rseau local vers internet Ignorer (DROP) toutes les tentatives de connexions d'internet vers le firewall ou vers votre rseau local et enregistrer dans vos journaux (log) un message au niveau info (vous trouverez ici la description des niveaux de journalisation). Rejeter (REJECT) toutes les autres demandes de connexion et gnrer un message de niveau info dans votre journal. Quant la requte est rejete et que le protocole est TCP, le firewall retourne un paquet RST. Pour tous les autres protocoles, quand une requte est rejete, le firewall renvoie un paquet ICMP port-unreachable. Maintenant, ditez votre /etc/shorewall/policy et apportez-y tous les changements que vous souhaitez.
Interfaces Rseau Dans la suite du guide, nous nous rfrerons au schma ci-dessous. Bien qu'il puisse ne pas correspondre votre propre rseau, il peut tre utilis pour illustrer les aspects importants de la configuration de Shorewall. Sur ce schma: La zone DMZ est compose des systmes DMZ 1 et DMZ 2. On utilise une DMZ pour isoler ses serveurs accessibles depuis internet de ses systmes locaux. Ainsi si un des serveurs de la DMZ est compromis, vous avez encore un firewall entre le systme compromis et vos systmes locaux. La zone local est compose des systmes Local 1, Local 2 et Local 3. Tous les systmes l'extrieur du firewall, y compris ceux de votre FAI, sont dans la zone internet. La faon la plus simple pour dfinir les zones est d'associer le nom de la zone (dfinie prcdemment dans /etc/shorewall/zones) une interface rseau. Ceci est fait dans le fichier /etc/shorewall/interfaces. Le firewall illustr ci-dessus trois interfaces rseau. Lorsque la connexion internet passe par un modem cble 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. Si votre interface vers l'extrieur est ppp0 ou ippp0 alors vous mettrez CLAMPMSS=yes dans le fichier /etc/shorewall/shorewall.conf. Votre Interface locale sera un adaptateur ethernet (eth0, eth1 or eth2) et sera connecte un hub ou un switch. Vos ordinateurs locaux seront connects ce mme hub ou switch (note : si vous n'avez qu'un seul ordinateur en local, vous pouvez le connecter directement au firewall par un cble crois). Votre interface DMZ sera aussi un adaptateur ethernet (eth0, eth1 or eth2) et sera connect un hub ou un switch. Vos ordinateurs appartenant la DMZ seront connects ce mme hub ou switch (note : si vous n'avez qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement au firewall par un cble crois). Ne connectez pas les interfaces interne et externe sur le mme hub ou le mme switch, sauf des fins de test. Vous pouvez tester en utilisant ce type de configuration si vous spcifiez l'option arp_filter ou l'option arp_ignore dans le fichier /etc/shorewall/interfaces, et ce pour toutes les interfaces connectes au hub/switch commun. Il est trs fortement dconseill d'utiliser une telle configuration avec un firewall en production. Dans la suite, nous supposerons que: L'interface externe est eth0. L'interface locale est eth1. L'interface DMZ est eth2. La configuration par dfaut de Shorewall ne dfinit le contenu d'aucune zone. Pour dfinir la configuration prsente plus haut, le fichier /etc/shorewall/interfaces doit contenir: #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect rfc1918 loc eth1 detect dmz eth2 detect Remarquez que la zone $FW n'a aucune entre dans le fichier /etc/shorewall/interfaces. ditez le fichier /etc/shorewall/interfaces. Dfinissez les interfaces du rseau de votre firewall et associez chacune d'entre elles une zone. Si vous avez une zone qui est connecte par plus d'une interface, incluez simplement une entre pour chaque interface et rptez le nom de zone autant de fois que ncessaire. Interfaces Multiples associes une Zone #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect rfc1918 loc eth1 detect loc eth2 detect Vous pouvez dfinir des zones plus compliques en utilisant le fichier /etc/shorewall/hosts mais dans la plus part des cas, cela ne sera pas ncessaire. Vous trouverez des exemples dans Shorewall_and_Aliased_Interfaces.html et Multiple_Zones.html.
Adressage, Sous-rseaux et Routage Normalement, votre FAI vous attribue un ensemble d'adresses IP publiques. Vous utiliserez une de ces adresses pour configurer l'interface externe de votre firewall. Vous dciderez ensuite comment utiliser le reste de vos adresses. Avant d'aborder ce point, il nous faut rappeler le contexte. Si vous tes dj familier de l'adressage IP et du routage, vous pouvez directement aller la prochaine section. La prsentation qui suit ne fait que d'effleurer les questions de l'adressage et du routage. Si vous vous voulez en apprendre plus sur l'adressage IP et le routage, je vous recommande IP Fundamentals: What Everyone Needs to Know about Addressing & Routing, Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0 (lien).
Adressage IP Les adresses IP version 4 (IPv4) sont codes sur 32 bits. La notation w.x.y.z fait rfrence une adresse dont l'octet de poids fort a pour valeur w, le suivant a pour valeur x, etc. Si nous prenons l'adresse 192.0.2.14 et que nous l'exprimons en hexadcimal, nous obtenons C0.00.02.0Eet si nous la regardons comme un entier de 32 bits nous avons C000020E
Sous-rseaux Vous entendrez encore aujourd'hui les termes de Rseau de classe A, Rseau de classe B et Rseau de classe C. Au dbut de l'existence de l'IP, les rseaux ne pouvaient avoir que trois tailles (il y avait aussi les rseaux de classe D mais il taient utiliss diffremment): Classe A - masque de sous-rseau 255.0.0.0, taille = 2 ** 24 Classe B - masque de sous-rseau 255.255.0.0, taille = 2 ** 16 Classe C - masque de sous-rseau 255.255.255.0, taille = 256 La classe d'un rseau tait dtermine de faon unique par la valeur de l'octet de poids fort de son adresse, ainsi en regardant une adresse IP on pouvait dterminer immdiatement la valeur du masque rseau. Le masque rseau est un nombre qui combin une adresse par un ET logique, isole l'adresse du rseau auquel cette adresse appartient. Le reste de l'adresse est le numro d'hte. Par exemple, dans l'adresse de classe C 192.0.2.14, la valeur hexadcimale de l'adresse du rseau est C00002 et le numro d'hte est 0E. Comme internet se dveloppait, il devint clair qu'un partitionnement aussi grossier de l'espace d'adresses de 32 bits allait tre trs limitatif (rapidement, les grandes socits et les universits s'taient dj attribues leur propre rseau de classe A !). Aprs quelques faux dparts, la technique courante du sous-adressage de ces rseaux en plus petits sous-rseaux volua. On fait rfrence cette technique sous l'appellation de Routage Inter-Domaine Sans Classe ou Classless InterDomain Routing (CIDR). Aujourd'hui, les systmes avec lesquels vous travaillez sont probablement compatibles avec la notation CIDR. La gestion des rseaux base sur les Classes est du domaine du pass. Un sous-rseau (subnet ou subnetwork) est un ensemble contigu d'adresses IP tel que: Le nombre d'adresses dans le jeu est un multiple de 2. La premire adresse dans le jeu est un multiple de la taille du jeu. La premire adresse du sous-rseau est rserve et on s'y rfre comme tant l'adresse du sous-rseau. La dernire adresse du sous-rseau est rserve comme adresse de diffusion (broadcast) du sous-rseau. Comme vous pouvez le constater par cette dfinition, dans chaque sous-rseau de taille n il y a (n - 2) adresses utilisables (adresses qui peuvent tre attribues un hte). La premire et la dernire adresse du sous-rseau sont utilises respectivement pour identifier l'adresse du sous-rseau et l'adresse de diffusion du sous-rseau. En consquence, de petits sous-rseaux sont plus gourmands en adresses IP que des sous-rseaux plus tendus. Comme n est une puissance de deux, nous pouvons aisment calculer le Logarithme base 2 de n (log2). La taille et le logarithme base 2 pour les tailles de sous-rseau les plus communes sont donns par la table suivante: Logarithmes base 2 n log2 n (32 - log2 n) 8 3 29 16 4 28 32 5 27 64 6 26 128 7 25 256 8 24 512 9 23 1024 10 22 2048 11 21 4096 12 20 8192 13 19 16384 14 18 32768 15 17 65536 16 16
Vous constaterez que la table ci-dessus contient aussi une colonne (32 - log2 n). Ce nombre est le Masque de Sous-rseau Longueur Variable ou Variable Length Subnet Mask (VLSM) pour un sous-rseau de taille n. De la table ci-dessus, nous pouvons dduire la suivante, qui est plus facile utiliser. VLSM Taille du sous-rseau VLSM Masque de sous-rseau 8 /29 255.255.255.248 16 /28 255.255.255.240 32 /27 255.255.255.224 64 /26 255.255.255.192 128 /25 255.255.255.128 256 /24 255.255.255.0 512 /23 255.255.254.0 1024 /22 255.255.252.0 2048 /21 255.255.248.0 4096 /20 255.255.240.0 8192 /19 255.255.224.0 16384 /18 255.255.192.0 32768 /17 255.255.128.0 65536 /16 255.255.0.0 2 ** 24 /8 255.0.0.0
Notez que le VLSM est crit avec un slash (/) -- vous entendrez souvent nommer un rseau de taille 64 comme tant un slash 26 et un de taille 8 comme tant un slash 29. Le masque de sous-rseau est simplement un nombre de 32 bits avec les premiers bits correspondant au VLSM positionns 1 et les bits suivants 0. Par exemple, pour un sous-rseau de taille 64, le masque de sous-rseau dbute par 26 bits 1: 11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 = 255.255.255.192Le masque de sous-rseau a la proprit suivante: si vous appliquez un ET logique entre le masque de sous-rseau et une adresse dans le sous-rseau, le rsultat est l'adresse du sous-rseau. Tout aussi important, si vous appliquer un ET logique entre le masque de sous-rseau et une adresse en dehors du sous-rseau, le rsultat n'est PAS l'adresse du sous-rseau. Comme nous le verrons aprs, cette proprit du masque de sous-rseau est trs importante dans le routage. Pour un sous-rseau dont l'adresse est a.b.c.d et dont le VLSM est /v, nous notons le sous-rseau a.b.c.d/v en utilisant la notation CIDR. Un exemple de sous-rseau : Sous-rseau: 10.10.10.0 - 10.10.10.127 Taille du sous-rseau: 128 Adresse du sous-rseau: 10.10.10.0 Adresse de diffusion: 10.10.10.127 Notation CIDR: 10.10.10.0/25
Il existe deux sous-rseaux dgnrs qui doivent tre mentionns: le sous-rseau avec un seul membre et le sous-rseau avec 2 ** 32 membres. /32 and /0 Taille du sous-rseau Longueur VLSM Masque de sous-rseau Notation CIDR 1 32 255.255.255.255 a.b.c.d/32 32 0 0.0.0.0 0.0.0.0/0
Ainsi, chaque adresse a.b.c.d peut aussi tre crite a.b.c.d/32 et l'ensemble des adresses possibles est crit 0.0.0.0/0. Un utilisateur de Shorewall a propos cette trs utile reprsentation graphique de ces informations. Dans la suite, nous utiliserons la notation a.b.c.d/v pour dcrire la configuration IP d'une interface rseau (l'utilitaire ip utilise aussi cette syntaxe). Dans cette notation l'interface est configure avec une adresse ip a.b.c.d avec le masque de sous-rseau qui correspond au VLSM /v. 192.0.2.65/29 L'interface est configure avec l'adresse IP 192.0.2.65 et le masque de sous-rseau 255.255.255.248. /sbin/shorewall propose une commande ipcalc qui calcule automatiquement les informations d'un [sous-]rseau. Utiliser la commande <command><command>ipcalc</command></command>. shorewall ipcalc 10.10.10.0/25 CIDR=10.10.10.0/25 NETMASK=255.255.255.128 NETWORK=10.10.10.0 BROADCAST=10.10.10.127 Utiliser la commande <command><command>ipcalc</command></command>. shorewall ipcalc 10.10.10.0 255.255.255.128 CIDR=10.10.10.0/25 NETMASK=255.255.255.128 NETWORK=10.10.10.0 BROADCAST=10.10.10.127
Routage L'un des objectifs de la gestion en sous-rseaux est qu'elle pose les bases pour le routage. Ci-dessous se trouve la table de routage de mon firewall: [root@gateway root]# netstat -nr Kernel IP routing table Destination Gateway Genmask Flgs MSS Win irtt Iface 192.168.9.1 0.0.0.0 255.255.255.255 UH 40 0 0 texas 206.124.146.177 0.0.0.0 255.255.255.255 UH 40 0 0 eth1 206.124.146.180 0.0.0.0 255.255.255.255 UH 40 0 0 eth3 192.168.3.0 0.0.0.0 255.255.255.0 U 40 0 0 eth3 192.168.2.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2 206.124.146.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 192.168.9.0 192.0.2.223 255.255.255.0 UG 40 0 0 texas 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo 0.0.0.0 206.124.146.254 0.0.0.0 UG 40 0 0 eth0 [root@gateway root]# L'interface texas est un tunnel GRE vers un site pair Dallas, au Texas. Les trois premires routes sont des routes vers des htes (host routes) puisqu'elles indiquent comment aller vers un hte unique. Dans la sortie de netstat, cela se voit trs bien au masque de sous-rseau (Genmask) 255.255.255.255, ou bien au drapeau H dans la colonne Flags . Les autres routes sont des routes rseau car elles indiquent au noyau comment router des paquets un sous-rseau. La dernire route est la route par dfaut. La passerelle mentionne dans cette route est appele la passerelle par dfaut (default gateway). Quant le noyau essaye d'envoyer un paquet une adresse IP A, il commence au dbut de la table de routage et: Il ralise un ET logique entre A et la valeur du masque de sou-rseau pour cette entre de la table. Ce rsultat est compar avec la valeur de la Destination dans cette entre de la table. Si le rsultat et la valeur de la Destination sont identiques, alors: Si la colonne Gateway n'est pas nulle, le paquet est envoy la passerelle par l'interface nomme dans la colonne Iface. Sinon, le paquet est directement envoy A travers l'interface nomme dans la colonne iface. Sinon, les tapes prcdentes sont rptes sur l'entre suivante de la table. Puisque la route par dfaut correspond toutes les adresses IP (A ET 0.0.0.0 = 0.0.0.0), les paquets qui ne correspondent aucune des autres entres de la table de routage sont envoys la passerelle par dfaut qui est gnralement un routeur de votre FAI. Prenons un exemple. Supposons que vous souhaitiez router un paquet 192.168.1.5. Cette adresse ne correspond aucune route d'hte dans la table mais lorsque nous faisons le ET logique de cette adresse avec 255.255.255.0, le rsultat est 192.168.1.0 qui correspond cette entre de la table: 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2 Donc, pour router ce paquet 192.168.1.5, il faudra le transmettre directement l'interface eth2. Un point important doit tre soulign -- tous les paquets sont envoys en utilisant la table de routage et les paquets en rponse ne sont pas un cas particulier. Il semble exister une ide fausse comme quoi les paquets rponses seraient comme les saumons et contiendraient une sorte de code gntique qui leur permettrait suivre la mme route emprunte par les paquets de requte (request) l'aller. Ce n'est pas le cas. Les rponses peuvent prendre un chemin totalement diffrent de celui pris par les paquets de la requte client l'aller -- Ces routes sont totalement indpendantes.
Protocole de Rsolution d'Adresse (ARP) Quant on envoie des paquets sur ethernet, les adresses IP ne sont pas utilises. L'adressage ethernet est bas sur les adresses MAC (Media Access Control). Chaque carte ethernet sa propre adresse MAC unique qui est grave dans une PROM lors de sa fabrication. Vous pouvez obtenir l'adresse MAC d'une carte ethernet grce l'utilitaire ip: [root@gateway root]# ip addr show 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 inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0 [root@gateway root]# Comme vous pouvez le constater, l'adresse MAC est code sur 6 octets (48 bits). L'adresse MAC est gnralement imprime sur la carte elle-mme. Comme IP utilise les adresses IP et ethernet les adresses MAC, il faut un mcanisme pour transcrire une adresse IP en adresse MAC. C'est ce dont est charg le protocole de rsolution d'adresse (Address Resolution Protocol ARP). Voici ARP en action: [root@gateway root]# tcpdump -nei eth2 arp tcpdump: listening on eth2 09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254 09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0 2 packets received by filter 0 packets dropped by kernel [root@gateway root]# Dans cet change , 192.168.1.254 (MAC 2:0:8:e3:4c:48) veut connatre l'adresse MAC du priphrique qui a l'adresse IP 192.168.1.19. Le systme ayant cette adresse IP rpond que l'adresse MAC du priphrique avec l'adresse IP 192.168.1.19 est 0:6:25:aa:8a:f0. Afin de ne pas avoir changer des information ARP chaque fois qu'un paquet doit tre envoy, le systme maintient un cache des correspondances IP<-> MAC. Vous pouvez voir le contenu du cache ARP sur votre systme (y compris sur les systmes Windows) en utilisant la commande arp [root@gateway root]# arp -na ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1 ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2 ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2 ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0 ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2 Les points d'interrogation au dbut des lignes sont le rsultat de l'utilisation de l'option n qui empche le programme arp de rsoudre le noms DNS pour les adresses IP (la commande arp de Windows n'accepte pas cette option) . Si je n'avais pas utilis pas cette option, les points d'interrogation seraient remplacs par les noms pleinement qualifis (FQDN) correspondant chaque adresse IP. Remarquez que la dernire information dans le cache correspond celle que nous avons vue en utilisant tcpdump l'instant.
RFC 1918 Les adresses IP sont alloues par l'IANA (Internet Assigned Number Authority) qui dlgue les allocations sur une base gographique aux Registres Internet Rgionaux (RIR). Par exemple, les allocations pour les Etats-Unis et l'Afrique sub-Saharienne sont dlgues l'ARIN (American Registry for Internet Numbers). Ces RIRs peuvent leur tour dlguer des bureaux nationaux. La plupart d'entre nous ne traite pas avec ces autorits mais obtient plutt ses adresse IP de son FAI. Dans la ralit, on ne peut en gnral pas se permettre d'avoir autant d'adresses IP publiques que l'on a de priphriques en ncessitant une. C'est cette raison qui nous amne utiliser des adresses IP prives. La RFC 1918 rserve plusieurs plages d'adresses cette fin : 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 Les adresses rserves par la RFC 1918 sont parfois appeles non-routables car les routeurs d'infrastructure internet ne feront pas suivre (forward) les paquets qui ont une adresse de destination de la RFC 1918. Cela est comprhensible puisque chacun peut choisir n'importe laquelle ces adresses pour son usage priv. Mais le terme de non-routable est quelque peu malencontreux car il peut amener conclure de manire errone que le trafic destin une de ces adresses ne peut tre envoy travers un routeur. Ceci est faux et les routeurs privs, dont votre firewall Shorewall, peuvent parfaitement faire suivre du trafic avec des adresses conformes la RFC 1918. Quant on choisit des adresses dans ces plages, il faut bien avoir l'esprit les choses suivantes: Comme l'espace des adresses IPv4 s'puise, de plus en plus d'organisation (y compris les FAI) commencent utiliser les adresses RFC 1918 dans leurs infrastructures. Vous ne devez pas utiliser d'adresse IP qui soit utilise par votre FAI ou une autre organisation avec laquelle vous souhaitez tablir une liaison VPN C'est pourquoi c'est une bonne ide de vrifier aprs de votre FAI s'il n'utilise pas (ou ne prvoie pas d'utiliser) des adresses prives avant de dcider quelles adresses que vous allez utiliser. Dans ce document, les adresses IP externes relles sont dans la plage 192.0.2.x. Les adresses du rseau 192.0.2.0/24 sont rserves par RFC 3330 pour l'utilisation d'adresses IP publiques dans les exemples imprims ainsi que dans les rseaux de test. Ces adresses ne doivent pas tre confondues avec les adresses 192.168.0.0/16, qui comme dcrit ci-dessus, sont rserves par la RFC 1918 pour une utilisation prive.
Configurer votre Rseau Le choix d'une configuration pour votre rseau dpend d'abord du nombre d'adresses IP publiques dont vous disposez et du nombre d'adresses IP dont vous avez besoin. Quel que soit le nombre d'adresses dont vous disposez, votre FAI peut vous servir ce jeu d'adresses de deux manires: Routes - Le trafic vers chacune de vos adresses publiques sera rout travers une seule adresse de passerelle. Cela sera gnralement fait si votre FAI vous attribue un sous-rseau complet (/29 ou plus). Dans ce cas, vous affecterez l'adresse de cette passerelle comme tant l'adresse de l'interface externe de votre firewall/routeur. Non routes - Votre FAI enverra le trafic chacune de vos adresses directement. Dans les paragraphes qui suivent, nous tudierons chacun de ces cas sparment. Avant de commencer, il y a une chose que vous devez vrifier: Si vous utilisez un paquetage Debian, vrifiez votre fichier shorewall.conf afin de vous assurer que les paramtres suivants sont convenablement fixs. Si ce n'est pas le cas, appliquez les changements ncessaires: IP_FORWARDING=On
Rout Supposons que votre fournisseur d'accs vous ait assign le sous-rseau 192.0.2.64/28 rout par 192.0.2.65. Vous avez les adresses IP 192.0.2.64 - 192.0.2.79 et l'adresse externe de votre firewall est 192.0.2.65. Votre FAI vous a aussi dit que vous devez utiliser le masque de sous-rseau 255.255.255.0 (ainsi, votre /28 est un sous-ensemble du /24, plus grand). Avec autant d'adresses IP, vous pouvez scinder votre rseau /28 en deux sous-rseaux /29 et configurer votre rseau comme l'indique le diagramme suivant. Dans l'exemple, la zone dmilitaris DMZ est dans le sous-rseau 192.0.2.64/29 et le rseau local est dans 192.0.2.72/29. La passerelle par dfaut pour les htes dans la DMZ doit tre configure 192.0.2.66 et la passerelle par dfaut pour ceux du rseau local doit tre configure 192.0.2.73. Notez que cette solution est plutt gourmande en adresses publiques puisqu'elle utilise 192.0.2.64 et 192.0.2.72 pour les adresses de sous-rseau, 192.0.2.71 et 192.0.2.79 pour les adresses de diffusion (broadcast) du rseau, et 192.0.2.66 et 168.0.2.73 pour les adresses internes sur le firewall/routeur. Elle montre nammoins comment la gestion en sous-rseaux peut fonctionner. Et si nous avions un rseau /24 plutt qu'un /28, l'utilisation de 6 adresses IP parmi les 256 disponibles serait largement justifie par la simplicit du paramtrage. Le lecteur attentif aura peut-tre remarqu que l'interface externe du firewall/Routeur est en fait incluse dans le sous-rseau DMZ (192.0.2.64/29). On peut se demander ce qui se passe quand l'hte DMZ 1 (192.0.2.67) essaye de communiquer avec 192.0.2.65. La table de routage sur l'hte DMZ 1 doit ressembler cela: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.0.2.64 0.0.0.0 255.255.255.248 U 40 0 0 eth0 0.0.0.0 192.0.2.66 0.0.0.0 UG 40 0 0 eth0 Donc, lorsque l'hte DMZ 1 voudra communiquer avec 192.0.2.65, il enverra une requte ARP "qui-a 192.0.2.65" alors qu'aucune interface sur le segment ethernet DMZ n'a cette adresse IP. Assez bizarrement, le firewall rpondra la requte avec l'adresse MAC de sa propre interface DMZ ! DMZ 1 peut alors envoyer des trames ethernet adresses cette adresse MAC et les trames seront reues correctement par le firewall/routeur. L'avertissement fait plus haut qui dconseille trs fortement la connexion de plusieurs interfaces du firewall/routeur un mme hub ou switch est une consquence directe de ce comportement plutt inattendu d'ARP de la part du noyau Linux. Quant une requte ARP destine une des adresses du firewall/routeur est envoye par un autre systme connect au mme hub ou switch, toutes les interfaces du firewall qui y sont connectes peuvent rpondre ! C'est alors la course savoir quelle rponse c'est-ici atteindra la premire l'metteur de la requte.
Non rout Si vous tes dans la situation prcdente mais que votre trafic n'est pas rout par votre FAI, vous pouvez configurer votre rseau exactement comme dcrit plus haut, au prix d'une lgre contorsion supplmentaire: spcifiez simplement l'option proxyarp sur les trois interfaces du firewall dans le fichier /etc/shorewall/interfaces. La plupart d'entre nous n'ont pas le luxe d'avoir suffisamment d'adresses publiques IP pour configurer leur rseau comme indiqu dans l'exemple prcdent (mme si la configuration est route). Dans le reste de cette section, supposons que notre FAI nous ait assign la plage d'adresses IP 192.0.2.176-180, qu'il nous ait dit d'utiliser le masque de sous-rseau 255.255.255.0 et que la passerelle par dfaut soit 192.0.2.254. De toute vidence, ce jeu d'adresses ne comprend pas de sous-rseau et n'a pas suffisamment d'adresses pour toutes les interfaces de notre rseau. Nous pouvons utiliser quatre techniques diffrentes pour contourner ce problme. La traduction d'adresses source (Source Network Address Translation SNAT). La traduction d'adresses destination (Destination Network Address Translation DNAT) nomme aussi transfert ou suivi de port (Port Forwarding). Le Proxy ARP. La traduction d'adresses rseau (Network Address Translation NAT) laquelle on fait aussi rfrence sous l'appellation de un--un NAT (one-to-one NAT). Souvent, une combinaison de ces techniques est utilise. Chacune d'entre elles sera dtaille dans la section suivante.
SNAT Avec la SNAT, un segment interne du rseau local est configur en utilisant des adresses de la RFC 1918. Quant un hte A sur ce segment interne initie une connexion vers un hte B sur internet, le firewall/routeur rcrit les enttes IP de la requte pour utiliser une de vos adresses publiques IP en tant qu'adresse source. Quant B rpond et que la rponse est reue par le firewall, le firewall change l'adresse destination par celle de la RFC 1918 de A et transfre la rponse A. Supposons que vous dcidiez d'utiliser la SNAT sur votre zone locale. Supposons galement que vous utilisiez l'adresse publique 192.0.2.176 la fois comme adresse externe du firewall et comme adresse source des requtes internet envoyes depuis cette zone. On a assign la zone locale le sous-rseau 192.168.201.0/29 (masque de sous-rseau 255.255.255.248). Dans ce cas, les systmes de la zone locale seraient configurs avec 192.168.201.1 comme passerelle par dfaut (adresse IP de l'interface local du firewall). La SNAT est configure dans Shorewall avec le fichier /etc/shorewall/masq. #INTERFACE SUBNET ADDRESS eth0 192.168.201.0/29 192.0.2.176 Cet exemple utilise la technique normale qui assigne la mme adresse publique IP pour l'interface externe du firewall et pour la SNAT. Si vous souhaitez utiliser une adresse IP diffrente, vous pouvez soit utiliser les outils de configuration rseau de votre distribution Linux pour ajouter cette adresse IP, soit mettre la variable ADD_SNAT_ALIASES=Yes dans /etc/shorewall/shorewall.conf et Shorewall ajoutera l'adresse pour vous.
DNAT Quand la SNAT est utilise, il est impossible pour les htes sur internet d'initialiser une connexion avec un des systmes internes puisque ces systmes n'ont pas d'adresses publiques IP. La DNAT fournit une mthode pour autoriser des connexions slectionnes depuis internet. Supposons que votre fille souhaite hberger un serveur Web sur son systme "Local 3". Vous pourriez autoriser les connexions d'internet son serveur en ajoutant l'entre suivante dans le fichier /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT(S) PORT(S) DEST DNAT net loc:192.168.201.4 tcp www Si une des amies de votre fille avec une adresse A veut accder au serveur de votre fille, elle peut se connecter http://192.0.2.176 (l'adresse IP externe de votre firewall). Le firewall rcrira l'adresse IP de destination 192.168.201.4 (le systme de votre fille) et lui fera suivre la requte. Quand le serveur de votre fille rpondra, le firewall remettra l'adresse source 192.0.2.176 et retournera la rponse A. Cet exemple utilise l'adresse externe IP du firewall pour la DNAT. Vous pouvez utiliser une autre de vos adresses IP publiques. Pour cela, mettez-la dans la colonne ORIGINAL DEST de la rgle ci-dessus. Par contre, Shorewall n'ajoutera pas votre place cette adresse l'interface externe du firewall. Quand vous testez des rgles DNAT comme celles prsente plus haut, vous devez le faire depuis un client A L'EXTRIEUR DE VOTRE FIREWALL (depuis la zone net). Vous ne pouvez pas tester ces rgles de l'intrieur ! Pour quelques astuces sur la rsolution de problmes avec la DNAT, voyez les FAQ 1a et 1b.
Proxy ARP Le principe du proxy ARP est: On attribue un hte H derrire notre firewall une de nos adresses publiques A et on lui donne le mme masque de sous-rseau M que celui de l'interface externe du firewall. Le firewall rpond aux requtes ARP qui-a-l'adresse A mises par les htes l'extrieur du firewall. Lorsque c'est l'hte H qui met une requte qui-a-l'adresse pour un hte situ l'extrieur du firewall et appartenant au sous-rseau dfini par A et M, c'est le firewall qui rpondra H avec l'adresse MAC de l'interface du firewall laquelle est raccord H. Pour une description plus complte du fonctionnement du Proxy ARP, vous pouvez vous rfrer la Documentation du Proxy Shorewall. Supposons que nous dcidions d'utiliser le Proxy ARP sur la DMZ de notre exemple de rseau. Ici, nous avons assign les adresses IP 192.0.2.177 au systme DMZ 1 et 192.0.2.178 au systme DMZ 2. Remarquez que nous avons assign une adresse RFC 1918 et un masque de sous-rseau arbitraires l'interface DMZ de notre firewall. Cette adresse et ce masque ne sont pas pertinents - vrifiez juste que celle-ci n'est en conflit avec aucun autre sous-rseau dj dfini. La configuration du Proxy ARP est faite dans le fichier /etc/shorewall/proxyarp. #ADDRESS INTERFACE EXTERNAL HAVE ROUTE PERSISTANT 192.0.2.177 eth2 eth0 No 192.0.2.178 eth2 eth0 No La variable HAVE ROUTE tant No, Shorewall ajoutera les routes d'hte pour 192.0.2.177 et 192.0.2.178 par eth2. Les interfaces ethernet des machines DMZ 1 et DMZ 2 devront tre configures avec les adresses IP donnes plus haut, mais elles devront avoir la mme passerelle par dfaut que le firewall lui-mme (192.0.2.254 dans notre exemple). Autrement dit, elles doivent tre configures exactement comme si elles taient parallles au firewall plutt que derrire lui. Ne pas ajouter le(s) adresse(s) traites par le proxy ARP (192.0.2.177 et 192.0.2.178 dans l'exemple ci-dessus) l'interface externe du firewall (eth0 dans cet exemple). Un mot de mise en garde. En gnral, les FAI configurent leurs routeurs avec un timeout de cache ARP assez lev. Si vous dplacez un systme parallle votre firewall derrire le Proxy ARP du firewall, cela peut mettre des HEURES avant que ce systme ne puisse communiquer avec internet. Il y a deux choses que vous pouvez essayer de faire: (Salutations Bradey Honsinger) Une lecture de TCP/IP Illustrated, Vol 1 de Richard Stevens rvle qu'un paquet ARP gratuit (gratuitous) peut amener le routeur de votre FAI rafrachir son cache (section 4.7). Un paquet ARP gratuit est simplement une requte d'un hte demandant l'adresse MAC associe sa propre adresse IP. En plus de garantir que cette adresse IP n'est pas duplique, si l'hte qui envoie la commande ARP gratuit vient juste de changer son adresse matrielle ..., ce paquet force tous les autres htes...qui ont une entre dans leur cache ARP pour l'ancienne adresse matrielle mettre leurs caches jour Ce qui est exactement, bien sr, ce que vous souhaitez faire lorsque vous basculez un hte qui tait directement expos sur internet vers l'arrire de votre firewall Shorewall en utilisant le proxy ARP (ou en faisant du NAT un--un pour la mme raison). Heureusement, les versions rcentes du paquetage iputils de Redhat comprennent arping, dont l'option "-U" fait cela: arping -U -I <net if> <newly proxied IP> arping -U -I eth0 66.58.99.83 # for exampleStevens continue en mentionnant que certains systmes ne rpondent pas correctement la commande ARP gratuit, mais une recherche sur google pour arping -U semble dmontrer que cela fonctionne dans la plupart des cas. Vous pouvez appeler votre FAI et lui demander de purger l'entre obsolte de son cache ARP, mais la plupart ne voudront ou ne pourront le faire. Vous pouvez vrifier si le cache ARP de votre FAI est obsolte en utilisant ping et tcpdump. Supposez que vous pensez que la passerelle routeur a une entre ARP obsolte pour 192.0.2.177. Sur le firewall, lancez tcpdump de cette faon: tcpdump -nei eth0 icmp Maintenant depuis 192.0.2.177, pingez la passerelle de votre FAI (que nous supposons tre 192.0.2.254): ping 192.0.2.254 Nous pouvons maintenant observer le rsultat de tcpdump: 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF) 13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo replyRemarquez que l'adresse source MAC dans la requte echo est diffrente de l'adresse MAC de destination dans la rponse echo ! Dans ce cas, 0:4:e2:20:20:33 tait l'adresse MAC de l'interface rseau eth0 du firewall tandis que 0:c0:a8:50:b2:57 tait l'adresse MAC de la carte rseau de DMZ 1. En d'autre termes, le cache ARP de la passerelle associe encore 192.0.2.177 avec la carte rseau de DMZ 1 plutt qu'avec l'interface eth0 du firewall.
NAT un--un Avec le NAT un--un (one-to-one NAT), vous attribuez des adresses RFC 1918 vos systmes puis vous tablissez une correspondance un pour un de ces adresses avec les adresses IP publiques. Pour les occurrences des connexions sortantes, la traduction d'adresses sources (SNAT) sera alors effectue. Pour les occurrences des connexions entrantes, c'est la traduction d'adresses destination (DNAT) qui sera ralise. Voyons avec l'exemple prcdent du serveur web de votre fille tournant sur le systme Local 3. Souvenons-nous que dans cette configuration, le rseau local utilise la SNAT et qu'il partage l'IP externe du firewall (192.0.2.176) pour les connexions sortantes. On obtient ce rsultat grce l'entre suivante dans le fichier /etc/shorewall/masq: #INTERFACE SUBNET ADDRESS eth0 192.168.201.0/29 192.0.2.176 Supposons maintenant que vous ayez dcid d'allouer votre fille sa propre adresse IP (192.0.2.179) pour l'ensemble des connexions entrantes et sortantes. Vous pouvez faire cela en ajoutant cette entre dans le fichier /etc/shorewall/nat. #EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 192.0.2.179 eth0 192.168.201.4 No No Avec cette entre active, votre fille a sa propre adresse IP et les deux autres systmes locaux partagent l'adresse IP du firewall. Une fois que la relation entre 192.0.2.179 et192.168.201.4 est tablie avec l'entre ci-dessus dans le fichier nat, l'utilisation d'une rgle d'une rgle DNAT pour le serveur Web de votre fille n'est plus approprie -- vous devriez plutt utiliser une simple rgle ACCEPT: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT(S) PORT(S) DEST ACCEPT net loc:192.168.201.4 tcp www Un mot de mise en garde. En gnral, les FAI configurent leurs routeurs avec un timeout de cache ARP assez lev. Si vous dplacez un systme parallle votre firewall derrire le Proxy ARP du firewall, cela peut mettre des HEURES avant que ce systme ne puisse communiquer avec internet. Il y a deux choses que vous pouvez essayer de faire: (Salutations Bradey Honsinger) Une lecture de TCP/IP Illustrated, Vol 1 de Richard Stevens rvle qu'un paquet ARP gratuit (gratuitous) peut amener le routeur de votre FAI rafrachir son cache (section 4.7). Un paquet ARP gratuit est simplement une requte d'un hte demandant l'adresse MAC associe sa propre adresse IP. En plus de garantir que cette adresse IP n'est pas duplique, si l'hte qui envoie la commande ARP gratuit vient juste de changer son adresse matrielle ..., ce paquet force tous les autres htes...qui ont une entre dans leur cache ARP pour l'ancienne adresse matrielle mettre leurs caches jour Ce qui est exactement, bien sr, ce que vous souhaitez faire lorsque vous basculez un hte qui tait directement expos sur internet vers l'arrire de votre firewall Shorewall en utilisant le proxy ARP (ou en faisant du NAT un--un pour la mme raison). Heureusement, les versions rcentes du paquetage iputils de Redhat comprennent arping, dont l'option "-U" fait cela: arping -U -I <net if> <newly proxied IP> arping -U -I eth0 66.58.99.83 # for exampleStevens continue en mentionnant que certains systmes ne rpondent pas correctement la commande ARP gratuit, mais une recherche sur google pour arping -U semble dmontrer que cela fonctionne dans la plupart des cas. Vous pouvez appeler votre FAI et lui demander de purger l'entre obsolte de son cache ARP, mais la plupart ne voudront ou ne pourront le faire. Vous pouvez vrifier si le cache ARP de votre FAI est obsolte en utilisant ping et tcpdump. Supposez que vous pensez que la passerelle routeur a une entre ARP obsolte pour 192.0.2.177. Sur le firewall, lancez tcpdump de cette faon: tcpdump -nei eth0 icmp Maintenant depuis 192.0.2.177, pingez la passerelle de votre FAI (que nous supposons tre 192.0.2.254): ping 192.0.2.254 Nous pouvons maintenant observer le rsultat de tcpdump: 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF) 13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo replyRemarquez que l'adresse source MAC dans la requte echo est diffrente de l'adresse MAC de destination dans la rponse echo ! Dans ce cas, 0:4:e2:20:20:33 tait l'adresse MAC de l'interface rseau eth0 du firewall tandis que 0:c0:a8:50:b2:57 tait l'adresse MAC de la carte rseau de DMZ 1. En d'autre termes, le cache ARP de la passerelle associe encore 192.0.2.177 avec la carte rseau de DMZ 1 plutt qu'avec l'interface eth0 du firewall.
Rgles Shorewall dispose d'un mcanisme de macros comprenant des macros pour de nombreuses applications standard. Dans cette section nous n'utiliserons pas de macro. mais nous dfinirons les rgles directement. Avec les politiques dfinies plus tt dans ce document, vos systmes locaux (Local 1-3) peuvent accder n'importe quel serveur sur internet alors que la DMZ ne peut accder aucun autre hte, dont le firewall. A l'exception des rgles NAT qui entranent la traduction d'adresses et permettent aux requtes de connexion traduites de passer travers le firewall, la faon d'autoriser des requtes travers votre firewall est d'utiliser des rgles ACCEPT. Puisque les colonnes SOURCE PORT et ORIG. DEST. ne sont pas utilises dans cette section, elle ne seront pas affiches. Vous souhaiter certainement autoriser le ping entre vos zones: #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT net dmz icmp echo-request ACCEPT net loc icmp echo-request ACCEPT dmz loc icmp echo-request ACCEPT loc dmz icmp echo-request Supposons que vous avez des serveurs mail et pop3 actifs sur le systme DMZ 2, et un serveur Web sur le systme DMZ 1. Les rgles dont vous avez besoin sont: #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz:192.0.2.178 tcp smtp #Mail from #Internet ACCEPT net dmz:192.0.2.178 tcp pop3 #Pop3 from #Internet ACCEPT loc dmz:192.0.2.178 tcp smtp #Mail from local #Network ACCEPT loc dmz:192.0.2.178 tcp pop3 #Pop3 from local #Network ACCEPT $FW dmz:192.0.2.178 tcp smtp #Mail from the #Firewall ACCEPT dmz:192.0.2.178 net tcp smtp #Mail to the #Internet ACCEPT net dmz:192.0.2.177 tcp http #WWW from #Internet ACCEPT net dmz:192.0.2.177 tcp https #Secure WWW #from Internet ACCEPT loc dmz:192.0.2.177 tcp https #Secure WWW #from local #Network Si vous utilisez un serveur DNS public sur 192.0.2.177, vous devez ajouter les rgles suivantes: #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz:192.0.2.177 udp domain #UDP DNS from #Internet ACCEPT net dmz:192.0.2.177 tcp domain #TCP DNS from #Internet ACCEPT loc dmz:192.0.2.177 udp domain #UDP DNS from #Local Network ACCEPT loc dmz:192.0.2.177 tcp domain #TCP DNS from #Local Network ACCEPT $FW dmz:192.0.2.177 udp domain #UDP DNS from #the Firewall ACCEPT $FW dmz:192.0.2.177 tcp domain #TCP DNS from #the Firewall ACCEPT dmz:192.0.2.177 net udp domain #UDP DNS to #the Internet ACCEPT dmz:192.0.2.177 net tcp domain #TCPP DNS to #the Internet Vous souhaiterez probablement communiquer depuis votre rseau local avec votre firewall et les systmes en DMZ -- Je recommande SSH qui, grce son utilitaire scp peut aussi faire de la diffusion et de la mise jour de logiciels. #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT loc dmz tcp ssh #SSH to the DMZ ACCEPT net $FW tcp ssh #SSH to the #Firewall
D'autres petites choses La discussion prcdente reflte ma prfrence personnelle pour l'utilisation d'un Proxy ARP associ mes serveurs en DMZ et de SNAT/NAT pour les systmes locaux. Je prfre utiliser la NAT seulement dans le cas ou un systme qui fait partie d'un sous-rseau RFC 1918 besoin d'avoir sa propre adresse IP publique. Si vous ne l'avez dj fait, ce serait une bonne ide de parcourir le fichier /etc/shorewall/shorewall.conf juste pour voir si autre chose pourrait vous intresser. Vous pouvez aussi regarder les autres fichiers de configuration que vous n'avez pas touchs pour avoir un aperu des autres possibilits de Shorewall. Dans le cas ou vous auriez perdu le fil, vous trouverez ci-dessous un jeu final des fichiers de configuration pour le rseau de notre exemple. Seuls les fichiers de la configuration initiale qui ont t modifis sont prsents. /etc/shorewall/interfaces (Les "options" sont trs dpendantes des sites). #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect rfc1918,routefilter loc eth1 detect dmz eth2 detect La configuration dcrite ici ncessite que votre rseau soit dmarr avant que Shorewall ne puisse se lancer. Ceci laisse un petit intervalle de temps durant lequel vous n'avez pas la protection d'un firewall. Si vous remplacez le detect dans les entres ci-dessus par la valeurs des adresses de diffusion (broadcoast) relles, vous pouvez activer Shorewall avant de monter vos interfaces rseau. #ZONE INTERFACE BROADCAST OPTIONS net eth0 192.0.2.255 rfc1918 loc eth1 192.168.201.7 dmz eth2 192.168.202.7 /etc/shorewall/masq - Rseau Local #INTERFACE SUBNET ADDRESS eth0 192.168.201.0/29 192.0.2.176 /etc/shorewall/proxyarp - DMZ #ADDRESS EXTERNAL INTERFACE HAVE ROUTE 192.0.2.177 eth2 eth0 No 192.0.2.178 eth2 eth0 No /etc/shorewall/nat- Le systme de ma fille #EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 192.0.2.179 eth0 192.168.201.4 No No /etc/shorewall/rules#ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz icmp echo-request ACCEPT net loc icmp echo-request ACCEPT dmz loc icmp echo-request ACCEPT loc dmz icmp echo-request ACCEPT net loc:192.168.201.4 tcp www #Daughter's #Server ACCEPT net dmz:192.0.2.178 tcp smtp #Mail from #Internet ACCEPT net dmz:192.0.2.178 tcp pop3 #Pop3 from #Internet ACCEPT loc dmz:192.0.2.178 tcp smtp #Mail from local #Network ACCEPT loc dmz:192.0.2.178 tcp pop3 #Pop3 from local #Network ACCEPT $FW dmz:192.0.2.178 tcp smtp #Mail from the #Firewall ACCEPT dmz:192.0.2.178 net tcp smtp #Mail to the #Internet ACCEPT net dmz:192.0.2.177 tcp http #WWW from #Internet ACCEPT net dmz:192.0.2.177 tcp https #Secure WWW #from Internet ACCEPT loc dmz:192.0.2.177 tcp https #Secure WWW #from local #Network ACCEPT net dmz:192.0.2.177 udp domain #UDP DNS from #Internet ACCEPT net dmz:192.0.2.177 tcp domain #TCP DNS from #Internet ACCEPT loc dmz:192.0.2.177 udp domain #UDP DNS from #Local Network ACCEPT loc dmz:192.0.2.177 tcp domain #TCP DNS from #Local Network ACCEPT $FW dmz:192.0.2.177 udp domain #UDP DNS from #the Firewall ACCEPT $FW dmz:192.0.2.177 tcp domain #TCP DNS from #the Firewall ACCEPT dmz:192.0.2.177 net udp domain #UDP DNS to #the Internet ACCEPT dmz:192.0.2.177 net tcp domain #TCPP DNS to #the Internet ACCEPT loc dmz tcp ssh #SSH to the DMZ ACCEPT net $FW tcp ssh #SSH to the #Firewall
DNS Compte tenu des adresses RFC 1918 et des adresses publiques utilises dans cette configuration, la seule faon logique de faire est d'avoir des serveurs DNS interne et externe spars. Vous pouvez combiner les deux dans un unique serveur BIND 9 utilisant les vues (Views). Si vous n'tes pas intress par les vues BIND 9, vous pouvez allez la section suivante. Supposons que votre domaine est foobar.net. Vous voulez que les deux systmes en DMZ s'appellent www.foobar.net et mail.foobar.net, et vous voulez que les trois systmes locaux s'appellent winken.foobar.net, blinken.foobar.net et nod.foobar.net. Vous voulez que le firewall soit connu l'extrieur sous le nom de firewall.foobar.net, que son interface vers le rseau local soit nomme gateway.foobar.net et que son interface vers la DMZ soit dmz.foobar.net. Mettons le serveur DNS sur 192.0.2.177 qui sera aussi connu sous le nom de ns1.foobar.net. Le fichier /etc/named.conf devrait ressembler cela: options { directory "/var/named"; listen-on { 127.0.0.1 ; 192.0.2.177; }; transfer-format many-answers; max-transfer-time-in 60; allow-transfer { // Servers allowed to request zone tranfers <secondary NS IP>; }; }; logging { channel xfer-log { file "/var/log/named/bind-xfer.log"; print-category yes; print-severity yes; print-time yes; severity info; }; category xfer-in { xfer-log; }; category xfer-out { xfer-log; }; category notify { xfer-log; }; }; # # This is the view presented to our internal systems # view "internal" { # # These are the clients that see this view # match-clients { 192.168.201.0/29; 192.168.202.0/29; 127.0.0.0/8; 192.0.2.176/32; 192.0.2.178/32; 192.0.2.179/32; 192.0.2.180/32; }; # # If this server can't complete the request, it should use # outside servers to do so # recursion yes; zone "." in { type hint; file "int/root.cache"; }; zone "foobar.net" in { type master; notify no; allow-update { none; }; file "int/db.foobar"; }; zone "0.0.127.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.127.0.0"; }; zone "201.168.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.192.168.201"; }; zone "202.168.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.192.168.202"; }; zone "176.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.176"; }; zone "177.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.177"; }; zone "178.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.178"; }; zone "179.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.206.124.146.179"; }; }; # # This is the view that we present to the outside world # view "external" { match-clients { any; }; # # If we can't answer the query, we tell the client so # recursion no; zone "foobar.net" in { type master; notify yes; allow-update {none; }; file "ext/db.foobar"; }; zone "176.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.176"; }; zone "177.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.177"; }; zone "178.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.178"; }; zone "179.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.179"; }; }; Voici les fichiers du rpertoire /var/named (ceux qui ne sont pas prsents font en gnral partie de votre distribution BIND). db.192.0.2.176 - Zone inverse (reverse) pour l'interface externe du firewall ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32 ; Filename: db.192.0.2.176 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net. db.192.0.2.177 - Zone inverse pour le serveur www ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32 ; Filename: db.192.0.2.177 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net. db.192.0.2.178 - Zone inverse du serveur mail ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32 ; Filename: db.192.0.2.178 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net. db.192.0.2.179 - Zone inverse du serveur web public de votre fille ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32 ; Filename: db.192.0.2.179 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net. int/db.127.0.0 - Zone inverse pour localhost ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8 ; Filename: db.127.0.0 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001092901 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR localhost.foobar.net. int/db.192.168.201 - Zone inverse pour le rseau local. Cela ne sera visible que depuis les clients internes ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29 ; Filename: db.192.168.201 ; ############################################################ @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. ( 2002032501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR gateway.foobar.net. 2 86400 IN PTR winken.foobar.net. 3 86400 IN PTR blinken.foobar.net. 4 86400 IN PTR nod.foobar.net. int/db.192.168.202 - Zone inverse de l'interface DMZ du firewall ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29 ; Filename: db.192.168.202 ; ############################################################ @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. ( 2002032501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. ; ############################################################ ; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR dmz.foobar.net. int/db.foobar - Forward zone pour les clients internes. ;############################################################## ; Start of Authority for foobar.net. ; Filename: db.foobar ;############################################################## @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2002071501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ); minimum (1 day) ;############################################################ ; foobar.net Nameserver Records (NS) ;############################################################ @ 604800 IN NS ns1.foobar.net. ;############################################################ ; Foobar.net Office Records (ADDRESS) ;############################################################ localhost 86400 IN A 127.0.0.1 firewall 86400 IN A 192.0.2.176 www 86400 IN A 192.0.2.177 ns1 86400 IN A 192.0.2.177 mail 86400 IN A 192.0.2.178 gateway 86400 IN A 192.168.201.1 winken 86400 IN A 192.168.201.2 blinken 86400 IN A 192.168.201.3 nod 86400 IN A 192.168.201.4 dmz 86400 IN A 192.168.202.1 ext/db.foobar - Forward zone pour les clients externes ;############################################################## ; Start of Authority for foobar.net. ; Filename: db.foobar ;############################################################## @ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2002052901 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ); minimum (1 day) ;############################################################ ; Foobar.net Nameserver Records (NS) ;############################################################ @ 86400 IN NS ns1.foobar.net. @ 86400 IN NS <secondary NS>. ;############################################################ ; Foobar.net Foobar Wa Office Records (ADDRESS) ;############################################################ localhost 86400 IN A 127.0.0.1 ; ; The firewall itself ; firewall 86400 IN A 192.0.2.176 ; ; The DMZ ; ns1 86400 IN A 192.0.2.177 www 86400 IN A 192.0.2.177 mail 86400 IN A 192.0.2.178 ; ; The Local Network ; nod 86400 IN A 192.0.2.179 ;############################################################ ; Current Aliases for foobar.net (CNAME) ;############################################################ ;############################################################ ; foobar.net MX Records (MAIL EXCHANGER) ;############################################################ foobar.net. 86400 IN A 192.0.2.177 86400 IN MX 0 mail.foobar.net. 86400 IN MX 1 <backup MX>.
Quelques Points Garder en Mmoire Vous ne pouvez pas tester votre firewall depuis l'intrieur de votre rseau. Envoyer des requtes l'adresse IP externe de votre firewall ne signifie pas qu'elle seront associes votre interface externe ou la zone net. Tout trafic gnr par le rseau local sera associ l'interface locale et sera trait comme du trafic du rseau local ver le firewall (loc->fw). Les adresses IP sont des proprits des systmes, 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 rseau local. La seule conclusion que vous puissiez faire dans ce cas est que le lien entre le rseau local et le firewall fonctionne et que vous avez probablement la bonne adresse de passerelle par dfaut sur votre systme. Toutes les adresses IP configures 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 rgle 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 entre dans /etc/shorewall/hosts. Les paquets de retour (reply) ne suivent PAS automatiquement le chemin inverse de la requte d'origine. Tous les paquets sont routs en se rfrant la table de routage respective de chaque hte chaque tape du trajet. Ce problme se produit en gnral lorsque on installe un firewall Shorewall en parallle une passerelle existante et qu'on essaye d'utiliser des rgles DNAT dans Shorewall sans changer la passerelle par dfaut sur les systmes recevant les requtes transfres (forwarded). Les requtes passent dans le firewall Shorewall o l'adresse de destination IP est rcrite, mais la rponse revient par l'ancienne passerelle qui, elle, ne modifiera pas le paquet. Shorewall lui-mme n'a aucune notion du dedans et du dehors. Ces concepts dpendent de la faon dont Shorewall est configur.
Dmarrer et Arrter Votre Firewall La procdure d'installation configure votre systme pour lancer Shorewall ds le boot du systme, mais le lancement est dsactiv, de faon ce que votre systme ne tente pas de lancer Shorewall avant que la configuration ne soit termine. 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 arrt avec la commande shorewall stop. Lorsque le firewall est arrt, le routage est autoris sur les htes qui possdent une entre 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 Modifiez /etc/shorewall/routestopped pour y configurer les htes auxquels vous voulez accder lorsque le firewall est arrt. Si vous tes connect votre firewall depuis internet, n'essayez pas d'excuter une commande shorewall stop tant que vous n'avez pas ajout une entre dans /etc/shorewall/routestopped pour l'adresse IP partir de laquelle vous tes connect . De la mme manire, je vous dconseille d'utiliser shorewall restart; il est plus intressant de crer une configuration alternative et de la tester en utilisant la commande shorewall try
shorewall-docs-xml-4.5.21/Anti-Spoofing.xml0000644000175000017500000001110312222401136020407 0ustar teastepteastep
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-4.5.21/SplitDNS.xml0000644000175000017500000001643012222401136017402 0ustar teastepteastep
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 exerpts 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-4.5.21/Build.xml0000644000175000017500000005345312222401136017007 0ustar teastepteastep
Building Shorewall from Git Tom Eastep 2009 2010 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. This information is provided primarily for Shorewall developers. Users are expected to install from pre-built tarballs or packages.
Git Taxonomy The Shorewall Git tree at Sourceforge serves as the master repository for Shorewall 4.4 and later versions. It is not possible to simply export a directory from Git and run the install.sh script in that directory. A build step is required to produce a directory that is suitable for the install.sh script to run in.
trunk The development branch of each product is kept here. Shorewall-core. Shorewall Shorewall6 Shorewall-lite Shorewall6-lite Shorewall-init There are also several other directories which are described in the following sub-sections.
trunk/docs The stable release XML documents. Depending on the point in the release cycle, these documents may also apply to the current development version.
tools This is where the release and build tools are kept. There are two subordinate directories: trunk/tools/build Tools for building and uploading new releases. trunk/tools/web Tools for publishing web content
web The files from the web site that are maintained in HTML format. are kept in this directory.
release Added in Shorewall 4.4.22, this directory contains the files that contain release-dependent information (change.txt, releasenotes.txt, .spec files, etc). This is actually a symbolic link to ../release which has it's own Git repository.
Build Tools As described above, the build tools are kept in trunk/tools/build. They are described in the following sections.
setversion The setversion script updates the version number in a directory. The script is run with the current working directory being release.
setversion version
The version may either be a minor version or a patch version.
build This is the script that builds Shorewall 4.4 packages from Git. The script copies content from Git using the git archive command. It then uses that content to build the packages. In addition to the usual Gnu utilities, the following software is required: rpmbuild Required to build the RPM packages. xsltproc (libxslt) Required to convert the XML documents to other formats. Docbook XSL Stylesheets Required to convert the XML documents to other formats. Perl Required to massage some of the config files. xmlto Required to convert the XML manpages to manpages. Be sure that you have a recent version; I use 0.0.23. You should ensure that you have the latest scripts. The scripts change periodically as we move through the release cycles. The build44 script may need to be modified to fit your particular environment. There are a number of variables that are set near the top of the file: STYLESHEET Must point to the XHTML docbook.xsl stylesheet from your Docbook XSL Stylesheets installation. LOGDIR Directory where you want the build log placed. Defaults to the current working directory. RPMDIR Points to your RPM directory . DIR Directory where you want the release to be built. Defaults to the current working directory. GIT Shorewall GIT repository. The scripts assume that there will be a separate build directory per major release. To build a release, you cd to the appropriate directory and run the build script. The general form of the build command is:
build [ -options ] release [ prior release ]
where options are one or more of the following. If no options are given then all options are assumed t build tar files r build RPMs c Build the shorewall package. i Build the shorewall-init package. l Build the shorewall-lite package. 6 Build the shorewall6 package. L Build the shorewall6-lite package. h Build the html document package. x Build the xml document package. release The release version to build. Must match the version in the associated Git path. prior release The release to be used to generate patch files. Example 1 - Build Shorewall 4.4.7 and generate patches against 4.4.6:
build 4.4.7 4.4.6
Example 2 - Build Shorewall 4.2.7.1 Shorewall and generate patches against 4.4.7:
build -trc 4.4.7.1 4.4.7
build45 This is the script that builds Shorewall 4.5 packages from Git. The script copies content from Git using the git archive command. It then uses that content to build the packages. In addition to the usual Gnu utilities, the following software is required: rpmbuild Required to build the RPM packages. xsltproc (libxslt) Required to convert the XML documents to other formats. Docbook XSL Stylesheets Required to convert the XML documents to other formats. Perl Required to massage some of the config files. xmlto Required to convert the XML manpages to manpages. Be sure that you have a recent version; I use 0.0.23. You should ensure that you have the latest scripts. The scripts change periodically as we move through the release cycles. The build44 script may need to be modified to fit your particular environment. There are a number of variables that are set near the top of the file: STYLESHEET Must point to the XHTML docbook.xsl stylesheet from your Docbook XSL Stylesheets installation. LOGDIR Directory where you want the build log placed. Defaults to the current working directory. RPMDIR Points to your RPM directory . DIR Directory where you want the release to be built. Defaults to the current working directory. GIT Shorewall GIT repository. The scripts assume that there will be a separate build directory per major release. To build a release, you cd to the appropriate directory and run the build script. The general form of the build command is:
build [ -options ] release [ prior release ]
where options are one or more of the following. If no options are given then all options are assumed t build tar files r build RPMs c Build the shorewall-core package. i Build the shorewall-init package. l Build the shorewall-lite package. 6 Build the shorewall6 package. L Build the shorewall6-lite package. h Build the html document package. s Build the shorewall package. x Build the xml document package. release The release version to build. Must match the version in the associated Git path. prior release The release to be used to generate patch files. Example 1 - Build Shorewall 4.3.7 and generate patches against 4.3.6:
build45 4.5.7 4.5.6
Example 2 - Build Shorewall 4.5.7.1 Shorewall-core and generate patches against 4.5.7:
build45 -trc 4.5.7.1 4.5.7
upload This script is used to upload a release to www1.shorewall.net. The command is run in the build directory for the minor release of the product.
upload [ -products ] release
where products specifes the products to upload. If not given, all products are uploaded. This option is generally given only when uploading a patch release. c Upload the shorewall-core package. l Upload the shorewall-lite package. i Upload the shorewall-init package. s Upload the shorewall package. 6 Upload the shorewall6 package. L Upload the shorewall6-lite package. release The version number of the release to upload. Example 1 - Upload release 4.3.7:
upload 4.3.7
Example 2 - Upload shorewall-4.3.7.3:
upload -c 4.3.7.3
install.sh files Each product includes an install script (install.sh) that may be used to install the product on a machine or into a directory. By default, the scripts install the corresponding product into "/'; you can direct them to install into an empty existing directory by setting an environmental variable: DESTDIR (release 4.4.10 and later) PREFIX (all releases) There are a number of other environmental variables that you can set to cause the directory to be populated for a particular target environment: DEBIAN - Debian-based systems (Debian, Ubuntu, etc.) SUSE - SEL and OpenSuSE REDHAT - RHEL, CentOS, Foobar, etc. MAC - Apple MacIntosh (Shorewall and Shorewall6 packages only) CYGWIN - Cygwin under Windows (Shorewall and Shorewall6 packages only)
shorewall-docs-xml-4.5.21/useful_links.xml0000644000175000017500000001242112222401136020441 0ustar teastepteastep shorewall-docs-xml-4.5.21/Introduction.xml0000644000175000017500000005005312222401136020422 0ustar teastepteastep shorewall-docs-xml-4.5.21/Audit.xml0000644000175000017500000002500212222401136017003 0ustar teastepteastep
AUDIT Target Support 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 In early 2011, Thomas Graf submitted a set of patches to the Netfilter development list that implemented an AUDIT rule target. This is from the initial submittal:
This patch adds a new netfilter target which creates audit records for packets traversing a certain chain. It can be used to record packets which are rejected administraively as follows: -N AUDIT_DROP -A AUDIT_DROP -j AUDIT --type DROP -A AUDIT_DROP -j DROP A rule which would typically drop or reject a packet would then invoke the new chain to record packets before dropping them. -j AUDIT_DROP The module is protocol independant and works for iptables, ip6tables and ebtables. netfilter hook packet length incoming/outgoing interface MAC src/dst/proto for ethernet packets src/dst/protocol address for IPv4/IPv6 src/dst port for TCP/UDP/UDPLITE icmp type/code
The audited packets are sent to a daemon (auditd) that write the audit information to a log file. In a related post by Eric Paris, the following additional information was posted:
AUDIT exists because a very large number of gov't customers (Not just USA) have special requirements about how 'relevant' information is gathered and stored. They require centralization and standardization and require pretty formal documentation describing it's operation. The gov't certification authority has recently added a requirement that they be able to log 'illegal attempted network connections' via the approved audit facility. Thus, this patch.
The AUDIT target was included in Linux kernel 2.6.39.
Shorewall Support Shorewall support for the AUDIT target was added in 4.4.20. The support involves the following: A new "AUDIT Target" capability is added and is required for auditing support. To use AUDIT support with a capabilities file, that file must be generated using this or a later release. Use 'shorewall show capabilities' after installing this release to see if your kernel/iptables support the AUDIT target. In /etc/shorewall/policy's POLICY column, the policy (and default action, if any) may be followed by ':audit' to cause application of the policy to be audited. Only ACCEPT, DROP and REJECT policies may be audited. Example: #SOURCE DEST POLICY LOG # LEVEL net fw DROP:audit It is allowed to also specify a log level on audited policies resulting in both auditing and logging. Three new builtin targets that may be used in the rules file, in macros and in other actions. A_ACCEPT - Audits and accepts the connection request A_DROP - Audits and drops the connection request A_REJECT - Audits and rejects A log level may be supplied with these actions to provide both auditing and logging. Example: #ACTION SOURCE DEST PROTO A_ACCEPT:info loc net ... The BLACKLIST_DISPOSITION, MACLIST_DISPOSITION, SMURF_DISPOSITION and TCP_FLAGS_DISPOSITION options may be set as follows: BLACKLIST_DISPOSITION A_DROP or A_REJECT MACLIST_DISPOSITION A_DROP, A_REJECT unless MACLIST_TABLE=mangle SMURF_DISPOSITION This option was added in Shorewall 4.4.20 A_DROP TCP_FLAGS_DISPOSITION A_DROP or A_REJECT An 'audit' option has been added to the /etc/shorewall/blacklist file which causes the packets matching the entryto be audited. 'audit' may not be specified together with 'accept'. The builtin actions (dropBroadcast, rejNonSyn, etc.) now support an 'audit' parameter which causes all ACCEPT, DROP and REJECTs performed by the action to be audited. There are audited versions of the standard Default Actions (A_Drop and A_Reject). These actions audit everything they do which is probably more than you want; as a consequence, you probably will want to make your own copies of these actions and modify them to only audit the packets that you are interested in. In Shorewall 4.4.21, the standard Default Actions were parameterized, accepting three parameters: Pass 'audit' if you want all ACCEPTs, DROPs and REJECTs audited. Pass '-' otherwise. The action to be applied to Auth requests; the default depends on the first parameter: FIRST PARAMETER DEFAULT - REJECT audit A_REJECT The action to be applied to SMB traffic. The default depends on the first parameter: ACTION FIRST PARAMETER DEFAULT Reject - REJECT Drop - DROP Reject audit A_REJECT Drop audit A_DROP The parameters can be passed in the POLICY column of the policy file. SOURCE DEST POLICY net all DROP:Drop(audit):audit #Same as DROP:A_DROP:audit SOURCE DEST POLICY net all DROP:Drop(-,DROP) #DROP rather than REJECT Auth The parameters can also be specified in shorewall.conf: DROP_DEFAULT=Drop(-,DROP) #DROP Auth rather than REJECT
shorewall-docs-xml-4.5.21/IPSEC-2.6.xml0000644000175000017500000012231012222401136017103 0ustar teastepteastep
IPSEC Tom Eastep Roberto Sanchez 2004 2005 2006 2009 Thomas M. Eastep 2007 Roberto C. Sanchez 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. Shorewall does not configure IPSEC for you -- it rather configures netfilter to accomodate your IPSEC configuration. The information in this article is only applicable if you plan to have IPSEC end-points on the same system where Shorewall is used. While this article shows configuration of IPSEC using ipsec-tools, Shorewall configuration is exactly the same when using OpenSwan or FreeSwan. When running a Linux kernel prior to 2.6.20, the Netfilter+ipsec and policy match support are broken when used with a bridge device. The problem was corrected in Kernel 2.6.20 as a result of the removal of deferred FORWARD/OUTPUT processing of traffic destined for a bridge. See the "Shorewall-perl and Bridged Firewalls" article.
Shorwall and Kernel 2.6 IPSEC This is not a HOWTO for Kernel 2.6 IPSEC -- for that, please see http://www.ipsec-howto.org/. The 2.6 Linux Kernel introduced new facilities for defining encrypted communication between hosts in a network. The network administrator defines a set of Security Policies which are stored in the kernel as a Security Policy Database (SPD). Security policies determine which traffic is subject to encryption. Security Associations are created between pairs of hosts in the network (one SA for traffic in each direction); these SAs define how traffic is to be encrypted. Outgoing traffic that is to be encrypted according to the contents of the SPD requires an appropriate SA to exist. SAs may be created manually using setkey(8) but most often, they are created by a cooperative process involving the ISAKMP protocol and daemons such as racoon or isakmpd. Incoming traffic is verified against the SPD to ensure that no unencrypted traffic is accepted in violation of the administrator's policies. There are three ways in which IPSEC traffic can interact with Shorewall policies and rules: Traffic that is encrypted on the firewall system. The traffic passes through Netfilter twice -- first as unencrypted then encrypted. Traffic that is decrypted on the firewall system. The traffic passes through Netfilter twice -- first as encrypted then as unencrypted. Encrypted traffic that is passed through the firewall system. The traffic passes through Netfilter once. In cases 1 and 2, the encrypted traffic is handled by entries in /etc/shorewall/tunnels (don't be mislead by the name of the file -- transport mode encrypted traffic is also handled by entries in that file). The unencrypted traffic is handled by normal rules and policies. Under the 2.4 Linux Kernel, the association of unencrypted traffic and zones was made easy by the presence of IPSEC pseudo-interfaces with names of the form ipsecN (e.g. ipsec0). Outgoing unencrypted traffic (case 1.) was send through an ipsecN device while incoming unencrypted traffic (case 2) arrived from an ipsecN device. The 2.6 kernel-based implementation does away with these pseudo-interfaces. Outgoing traffic that is going to be encrypted and incoming traffic that has been decrypted must be matched against policies in the SPD and/or the appropriate SA. Shorewall provides support for policy matching in three ways: In /etc/shorewall/masq, traffic that will later be encrypted is exempted from MASQUERADE/SNAT using existing entries. If you want to MASQUERADE/SNAT outgoing traffic that will later be encrypted, you must include the appropriate indication in the new IPSEC column in that file. The /etc/shorewall/zones file allows you to associate zones with traffic that will be encrypted or that has been decrypted. A new option (ipsec) has been provided for entries in /etc/shorewall/hosts. When an entry has this option specified, traffic to/from the hosts described in the entry is assumed to be encrypted. In summary, Shorewall provides the facilities to replace the use of ipsec pseudo-interfaces in zone and MASQUERADE/SNAT definition. There are two cases to consider: Encrypted communication is used to/from all hosts in a zone. The value ipsec is placed in the TYPE column of the /etc/shorewall/zones entry for the zone. By default, encrypted communication is not used to communicate with the hosts in a zone. The value ipv4 is placed in the TYPE column of the /etc/shorewall/zones entry for the zone and the new ipsec option is specified in /etc/shorewall/hosts for any hosts requiring secure communication. For simple zones such as are shown in the following examples, the two techniques are equivalent and are used interchangeably. It is redundant to have ipsec in the TYPE column of the /etc/shorewall/zones entry for a zone and to also have the ipsec option in /etc/shorewall/hosts entries for that zone. Finally, the OPTIONS, IN OPTIONS and OUT OPTIONS columns in /etc/shorewall/zones can be used to match the zone to a particular (set of) SA(s) used to encrypt and decrypt traffic to/from the zone and the security policies that select which traffic to encrypt/decrypt. This article assumes the use of ipsec-tools (http://ipsec-tools.sourceforge.net). As of this writing, I recommend that you run at least version 0.5.2. Debian users, please note that there are separate Debian packages for ipsec-tools and racoon although the ipsec-tools project releases them as a single package. For more information on IPSEC, Kernel 2.6 and Shorewall see my presentation on the subject given at LinuxFest NW 2005. Be warned though that the presentation is based on Shorewall 2.2 and there are some differences in the details of how IPSEC is configured.
IPSec Gateway on the Firewall System Suppose that we have the following situation: We want systems in the 192.168.1.0/24 sub-network to be able to communicate with systems in the 10.0.0.0/8 network. We assume that on both systems A and B, eth0 is the Internet interface. To make this work, we need to do two things: Open the firewall so that the IPSEC tunnel can be established (allow the ESP protocol and UDP Port 500). Allow traffic through the tunnel. Opening the firewall for the IPSEC tunnel is accomplished by adding an entry to the /etc/shorewall/tunnels file. In /etc/shorewall/tunnels on system A, we need the following
/etc/shorewall/tunnels — System A: #TYPE ZONE GATEWAY GATEWAY ZONE ipsec net 134.28.54.2 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE /etc/shorewall/tunnels — System B: #TYPE ZONE GATEWAY GATEWAY ZONE ipsec net 206.162.148.9 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
If either of the endpoints is behind a NAT gateway then the tunnels file entry on the other endpoint should specify a tunnel type of ipsecnat rather than ipsec and the GATEWAY address should specify the external address of the NAT gateway. You need to define a zone for the remote subnet or include it in your local zone. In this example, we'll assume that you have created a zone called vpn to represent the remote subnet.
/etc/shorewall/zones — Systems A and B: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS net ipv4 vpn ipv4 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
Remember the assumption that both systems A and B have eth0 as their Internet interface. You must define the vpn zone using the /etc/shorewall/hosts file. The hosts file entries below assume that you want the remote gateway to be part of the vpn zone — If you don't wish the remote gateway included, simply omit its IP address from the HOSTS column.
/etc/shorewall/hosts — System A #ZONE HOSTS OPTIONS vpn eth0:10.0.0.0/8,134.28.54.2 ipsec #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE /etc/shorewall/hosts — System B #ZONE HOSTS OPTIONS vpn eth0:192.168.1.0/24,206.162.148.9 ipsec #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
Assuming that you want to give each local network free access to the remote network and vice versa, you would need the following /etc/shorewall/policy entries on each system:
#SOURCE DESTINATION POLICY LEVEL BURST:LIMIT loc vpn ACCEPT vpn loc ACCEPT
If you need access from each firewall to hosts in the other network, then you could add:
#SOURCE DESTINATION POLICY LEVEL BURST:LIMIT $FW vpn ACCEPT
If you need access between the firewall's, you should describe the access in your /etc/shorewall/rules file. For example, to allow SSH access from System B, add this rule on system A:
#ACTION SOURCE DESTINATION PROTO POLICY ACCEPT vpn:134.28.54.2 $FW
Note that your Security Policies must also be set up to send traffic between 134.28.54.2 and 206.162.148.9 through the tunnel (see below). Once you have these entries in place, restart Shorewall (type shorewall restart); you are now ready to configure IPSEC. For full encrypted connectivity in this configuration (between the subnets, between each subnet and the opposite gateway, and between the gateways), you will need eight policies in /etc/racoon/setkey.conf. For example, on gateway A:
# First of all flush the SPD and SAD databases spdflush; flush; # Add some SPD rules spdadd 192.168.1.0/24 10.0.0.0/8 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require; spdadd 192.168.1.0/24 134.28.54.2/32 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require; spdadd 206.162.148.9/32 134.28.54.2/32 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require; spdadd 206.162.148.9/32 10.0.0.0/8 any -P out ipsec esp/tunnel/206.162.148.9-134.28.54.2/require; spdadd 10.0.0.0/8 192.168.1.0/24 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require; spdadd 10.0.0.0/8 206.162.148.9/32 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require; spdadd 134.28.54.2/32 192.168.1.0/24 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require; spdadd 134.28.54.2/32 206.162.148.9/32 any -P in ipsec esp/tunnel/134.28.54.2-206.162.148.9/require;
The setkey.conf file on gateway B would be similar. A sample /etc/racoon/racoon.conf file using X.509 certificates might look like:
path certificates "/etc/certs" ; listen { isakmp 206.162.148.9; } remote 134.28.54.2 { exchange_mode main ; certificate_type x509 "GatewayA.pem" "GatewayA_key.pem" ; verify_cert on; my_identifier asn1dn ; peers_identifier asn1dn ; verify_identifier on ; lifetime time 24 hour ; proposal { encryption_algorithm blowfish; hash_algorithm sha1; authentication_method rsasig ; dh_group 2 ; } } sainfo address 192.168.1.0/24 any address 10.0.0.0/8 any { pfs_group 2; lifetime time 12 hour ; encryption_algorithm blowfish ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } sainfo address 206.162.148.9/32 any address 10.0.0.0/8 any { pfs_group 2; lifetime time 12 hour ; encryption_algorithm blowfish ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } sainfo address 206.162.148.9/32 any address 134.28.54.2/32 any { pfs_group 2; lifetime time 12 hour ; encryption_algorithm blowfish ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } sainfo address 192.168.1.0/24 any address 134.28.54.2/32 any { pfs_group 2; lifetime time 12 hour ; encryption_algorithm blowfish ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } If you have hosts that access the Internet through an IPSEC tunnel, then it is a good idea to set the MSS value for traffic from those hosts explicitly in the /etc/shorewall/zones file. For example, if hosts in the sec zone access the Internet through an ESP tunnel then the following entry would be appropriate: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS sec ipsec mode=tunnel mss=1400 You should also set FASTACCEPT=No in shorewall.conf to ensure that both the SYN and SYN,ACK packets have their MSS field adjusted. Note that CLAMPMSS=Yes in shorewall.conf isn't effective with the 2.6 native IPSEC implementation because there is no separate ipsec device with a lower mtu as there was under the 2.4 and earlier kernels.
Mobile System (Road Warrior) Suppose that you have a laptop system (B) that you take with you when you travel and you want to be able to establish a secure connection back to your local network. Road Warrior VPN You need to define a zone for the laptop or include it in your local zone. In this example, we'll assume that you have created a zone called vpn to represent the remote host.
/etc/shorewall/zones — System A #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS net ipv4 vpn ipsec loc ipv4 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
In this instance, the mobile system (B) has IP address 134.28.54.2 but that cannot be determined in advance. In the /etc/shorewall/tunnels file on system A, the following entry should be made:
#TYPE ZONE GATEWAY GATEWAY ZONE ipsec net 0.0.0.0/0 vpn #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
the GATEWAY ZONE column contains the name of the zone corresponding to peer subnetworks. This indicates that the gateway system itself comprises the peer subnetwork; in other words, the remote gateway is a standalone system. The VPN zone is defined using the /etc/shorewall/hosts file:
/etc/shorewall/hosts — System A: #ZONE HOSTS OPTIONS vpn eth0:0.0.0.0/0 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
You will need to configure your through the tunnel policy as shown under the first example above. On the laptop:
/etc/shorewall/zones - System B: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS vpn ipsec net ipv4 loc ipv4 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE /etc/shorewall/tunnels - System B: #TYPE ZONE GATEWAY GATEWAY ZONE ipsec net 206.162.148.9 vpn #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE /etc/shorewall/hosts - System B: #ZONE HOSTS OPTIONS vpn eth0:0.0.0.0/0 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
On system A, here are the IPSEC files:
/etc/racoon/racoon.conf - System A: path certificate "/etc/certs" ; listen { isakmp 206.162.148.9; } remote anonymous { exchange_mode main ; generate_policy on ; passive on ; certificate_type x509 "GatewayA.pem" "GatewayA_key.pem" ; verify_cert on; my_identifier asn1dn ; peers_identifier asn1dn ; verify_identifier on ; lifetime time 24 hour ; proposal { encryption_algorithm blowfish ; hash_algorithm sha1; authentication_method rsasig ; dh_group 2 ; } } sainfo anonymous { pfs_group 2; lifetime time 12 hour ; encryption_algorithm blowfish ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } /etc/racoon/setkey.conf - System A: flush; spdflush;
If system A is running kernel 2.6.10 or later then it must also be running ipsec-tools (racoon) 0.5rc1 or later. On the mobile system (system B), it is not possible to create a static IPSEC configuration because the IP address of the laptop's Internet connection isn't static. I have created an 'ipsecvpn' script and included in the tarball and in the RPM's documentation directory; this script can be used to start and stop the connection. The ipsecvpn script has some variable assignments at the top -- in the above case, these would be as follows:
# # External Interface # INTERFACE=eth0 # # Remote IPSEC Gateway # GATEWAY=206.162.148.9 # # Networks behind the remote gateway # NETWORKS="192.168.1.0/24" # # Directory where X.509 certificates are stored. # CERTS=/etc/certs # # Certificate to be used for this connection. The cert # directory must contain: # # ${CERT}.pem - the certificate # ${CERT}_key.pem - the certificates's key # CERT=roadwarrior # # The setkey binary # SETKEY=/usr/sbin/setkey # # The racoon binary # RACOON=/usr/sbin/racoon
The ipsecvpn script can be installed in /etc/init.d/ but it is probably best installed in /usr/local/sbin and run manually:
ipsecvpn start # Starts the tunnel ipsecvpn stop # Stops the tunnel
Although the ipsecvpn script allows you to specify multiple remote NETWORKS as a space-separated list, SAs are created on the gateway only during ISAKMP negotiation. So in practice, only the first remote network accessed will be accessible from the roadwarrior.
Mobile System (Road Warrior) with Layer 2 Tunneling Protocol (L2TP) This section is based on the previous section. Please make sure that you read it thoroughly and understand it. The setup described in this section is more complex because you are including an additional layer of tunneling. Again, make sure that you have read the previous section and it is highly recommended to have the IPSEC-only configuration working first. Additionally, this section assumes that you are running IPSEC, xl2tpd and pppd on the same system that is running shorewall. However, configuration of these additional services is beyond the scope of this document. Getting layer 2 tunneling to work is an endeavour unto itself. However, if you succeed it can be very convenient. Reasons why you might want configure layer 2 tunneling protocol (L2TP): You want to give your road warrior an address that is in the same segment as the other hosts on your network. Your road warriors are using a legacy operating system (such as MS Windows or Mac OS X) and you do not want them to have to install third party software in order to connect to the VPN (both MS Windows and Mac OS X include VPN clients which natively support L2TP over IPSEC, but not plain IPSEC). You like a challenge. Since the target for a VPN including L2TP will (almost) never be a road warrior running Linux, I will not include the client side of the configuration. The first thing that needs to be done is to create a new zone called l2tp to represent the tunneled layer 2 traffic.
/etc/shorewall/zones — System A #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS net ipv4 vpn ipsec l2tp ipv4 loc ipv4 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
Since the L2TP will require the use of pppd, you will end up with one or more ppp interfaces (each representing an individual road warrior connection) for which you will need to account. This can be done by modifying the interfaces file. (Modify with additional options as needed.)
/etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect routefilter loc eth1 192.168.1.255 l2tp ppp+ - #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
The next thing that must be done is to adjust the policy so that the traffic can go where it needs to go. First, you need to decide if you want for hosts in your local zone to be able to connect to your road warriors. You may or may not want to allow this. For example, one reason you might want to allow this is so that your support personnel can use ssh, VNC or remote desktop to fix a problem on the road warrior's laptop. Second, you need to decide if you want the road warrior to have access to hosts on the local network. You generally want to allow this. For example, if you have DNS servers on your local network that you want the road warrior to use. Or perhaps the road warrior needs to mount NFS shares or needs to access intranet sites which are not visible from the public Internet. Finally, you need to decide if you want the road warriors to be able to access the public Internet. You probably want to do this, unless you are trying to create a situation where when the road warrior connects to the VPN, it is no longer possible to send traffic from the road warrior's machine to the public Internet. Please note that this not really a strong security measure. The road warrior could trivially modify the routing table on the remote machine to have only traffic destined for systems on the VPN local network go through the secure channel. The rest of the traffic would simply travel over an Ethernet or wireless interface directly to the public Internet. In fact, this latter situation is dangerous, as a simple mistake could easily create a situation where the road warrior's machine is acting as a router between your local network and the public Internet, which you certainly do not want to happen. In short, it is best to allow the road warrior to connect to the public Internet by default.
/etc/shorewall/policy: #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST $FW all ACCEPT loc net ACCEPT loc l2tp ACCEPT # Allows local machines to connect to road warriors l2tp loc ACCEPT # Allows road warriors to connect to local machines l2tp net ACCEPT # Allows road warriors to connect to the Internet net all DROP info # The FOLLOWING POLICY MUST BE LAST all all REJECT info #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
The final step is to modify your rules file. There are three important components. First, you must allow the l2tp traffic to reach the xl2tpd process running on the firewall machine. Second, you must add rules to open up ports on the firewall to the road warrior for services which are running on the firewall. For example, if you are running a webserver on the firewall that must be accessible to road warriors. The reason for the second step is that the policy does not by default allow unrestricted access to the firewall itself. Finally, you should protect an exploit where an attacker can exploit your LT2P server due to a hole in the way that L2TP interacts with UDP connection tracking.
/etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST SOURCE # PORT(S) PORT(S) SECTION ESTABLISHED # Prevent IPSEC bypass by hosts behind a NAT gateway L2TP(REJECT) net $FW REJECT $FW net udp - 1701 # l2tp over the IPsec VPN ACCEPT vpn $FW udp 1701 # webserver that can only be accessed internally HTTP(ACCEPT) loc $FW HTTP(ACCEPT) l2tp $FW HTTPS(ACCEPT) loc $FW HTTPS(ACCEPT) l2tp $FW #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
Transport Mode In today's wireless world, it is often the case that individual hosts in a network need to establish secure connections with the other hosts in that network. In that case, IPSEC transport mode is an appropriate solution. Here's an example using the ipsec-tools package. The files shown are from host 192.168.20.10; the configuration of the other nodes is similar.
/etc/racoon/racoon.conf: path pre_shared_key "/etc/racoon/psk.txt" ; remote anonymous { exchange_mode main ; my_identifier address ; lifetime time 24 hour ; proposal { encryption_algorithm blowfish ; hash_algorithm sha1; authentication_method pre_shared_key ; dh_group 2 ; } } sainfo anonymous { pfs_group 2; lifetime time 12 hour ; encryption_algorithm blowfish ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } /etc/racoon/setkey.conf: # First of all flush the SPD database spdflush; # Add some SPD rules spdadd 192.168.20.10/32 192.168.20.20/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.20/require; spdadd 192.168.20.20/32 192.168.20.10/32 any -P in ipsec esp/transport/192.168.20.20-192.168.20.10/require; spdadd 192.168.20.10/32 192.168.20.30/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.30/require; spdadd 192.168.20.30/32 192.168.20.10/32 any -P in ipsec esp/transport/192.168.20.30-192.168.20.10/require; spdadd 192.168.20.10/32 192.168.20.40/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.40/require; spdadd 192.168.20.40/32 192.168.20.10/32 any -P in ipsec esp/transport/192.168.20.40-192.168.20.10/require; /etc/racoon/psk.txt: 192.168.20.20 <key for 192.168.20.10<->192.168.20.20> 192.168.20.30 <key for 192.168.20.10<->192.168.20.30> 192.168.20.40 <key for 192.168.20.10<->192.168.20.40> Note that the same keymust be used in both directions.
Shorewall configuration goes as follows:
/etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect routefilter,dhcp,tcpflags #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/tunnels: #TYPE ZONE GATEWAY GATEWAY # ZONE ipsec net 192.168.20.0/24 loc /etc/shorewall/zones: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS loc ipsec mode=transport net ipv4 /etc/shorewall/hosts: #ZONE HOST(S) OPTIONS loc eth0:192.168.20.0/24 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE It is worth noting that although loc is a sub-zone of net, because loc is an IPSEC-only zone it does not need to be defined before net in /etc/shorewall/zones. /etc/shorewall/policy: #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST $FW all ACCEPT loc $FW ACCEPT net loc NONE loc net NONE net all DROP info # The FOLLOWING POLICY MUST BE LAST all all REJECT info #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE Since there are no cases where net<->loc traffic should occur, NONE policies are used.
IPCOMP If your IPSEC tunnel or transport mode connection fails to work with Shorewall started and you see log messages like the following when you try to use the connection, the problem is that ip compression is being used.Feb 18 23:43:52 vpngw kernel: Shorewall:vpn2fw:REJECT:IN=eth2 OUT= MAC=00:e0:81:32:b3:5e:00:18:de:12:e5:15:08:00 SRC=172.29.59.58 DST=172.29.59.254 LEN=85 TOS=0x00 PREC=0x00 TTL=64 ID=25600 DF PROTO=4The solution is to add an IPCOMP tunnel to /etc/shorewall/tunnels as follows:#TYPE ZONE GATEWAY GATEWAY # ZONE ipip vpn 0.0.0.0/0The above assumes that the name of your IPSEC vpn zone is vpn.
IPSEC and <trademark>Windows</trademark> XP I have successfully configured my work laptop to use IPSEC with X.509 certificates for wireless IP communication when it is undocked at home. I looked at dozens of sites and the one I found most helpful was http://ipsec.math.ucla.edu/services/ipsec-windows.html. The instructions on that site are directed to students at UCLA but they worked fine for me (once I followed them very carefully). The instructions found on the UCLA site are complex and do not include any information on the generation of X.509 certificates. There are lots of sites however that can tell you how to generate certificates, including http://www.ipsec-howto.org/. One piece of information that may not be so easy to find is "How do I generate a PKCS#12 certificate to import into Windows?". Here's the openssl command that I used: openssl pkcs12 -export -in eastepnc6000.pem -inkey eastepnc6000_key.pem -out eastepnc6000.pfx -name "IPSEC Cert for Home Wireless" I was prompted for a password to associate with the certificate. This password is entered on the Windows system during import. In the above command: eastepnc6000.pem was the laptop's certificate in PEM format. eastepnc6000_key.pem was the laptop's private key (actually, it's the original signing request which includes the private key). eastepnc6000.pfx is the PKCS#12 output file. "IPSEC Cert for Home Wireless" is the friendly name for the certificate. I started to write an article about how to do this, complete with graphics captured from my laptop. I gave up. I had captured 12 images and hadn't really started yet. The Windows interface for configuring IPSEC is the worst GUI that I have ever used. What can be displayed on one split Emacs screen (racoon.conf plus setkey.conf) takes 20+ different dialog boxes on Windows XP!!!
Source of Additional Samples Be sure to check out the src/racoon/samples subdirectory in the ipsec-tools source tree. It has a wide variety of sample racoon configuration files.
shorewall-docs-xml-4.5.21/ping.xml0000644000175000017500000000674012222401136016702 0ustar teastepteastep
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 DEST PORT(S) Ping(ACCEPT) z1 z2 Ping from local zone to firewall To permit ping from the local zone to the firewall: #ACTION SOURCE DEST PROTO DEST PORT(S) 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 DEST PORT(S) 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 DEST PORT(S) 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-4.5.21/quotes.xml0000644000175000017500000001703012222401136017257 0ustar teastepteastep
Quotes from Users Tom Eastep 2003 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.
What Users are saying...
AS, Poland I want to say that Shorewall documentation is the best I've ever found on the net. It's helped me a lot in understanding how network is working. It is the best of breed. It contains not only Shorewall specific topics with the assumption that all the rest is well known, but also gives some very useful background information. Thank you very much for this wonderful piece of work.
ES, Phoenix AZ, USA I have fought with IPtables for untold hours. First I tried the SUSE firewall, which worked for 80% of what I needed. Then gShield, which also worked for 80%. Then I set out to write my own IPtables parser in shell and awk, which was a lot of fun but never got me past the hey, cool stage. Then I discovered Shorewall. After about an hour, everything just worked. I am stunned, and very grateful
SE, California, USA In two words, I'd call Shorewall "brilliant simplicity". Define general rules of what it is you want to do, and let the software determine the specific rules on how to implement it. It's great only having to define specific rules for specific instances. I have a much higher degree of confidence in my firewall than I have had previously. Thank you for Shorewall!.
BC, USA The configuration is intuitive and flexible, and much easier than any of the other iptables-based firewall programs out there. After sifting through many other scripts, it is obvious that yours is the most well thought-out and complete one available.
JL, Ohio I just installed Shorewall after weeks of messing with ipchains/iptables and I had it up and running in under 20 minutes!
JV, Spain My case was almost like [the one above]. Well. instead of weeks it was months for me, and I think I needed two minutes more: One to see that I had no Internet access from the firewall itself. Other to see that this was the default configuration, and it was enough to uncomment a line in /etc/shorewall/policy. Minutes instead of months! Congratulations and thanks for such a simple and well documented thing for something as huge as iptables
MM I downloaded Shorewall 1.2.0 and installed it on Mandrake 8.1 without any problems. Your documentation is great and I really appreciate your network configuration info. That really helped me out alot. THANKS!!!
B.R, Netherlands [Shorewall is a] great, great project. I've used/tested may firewall scripts but this one is till now the best.
Mario Kerecki, Toronto Never in my +12 year career as a sys admin have I witnessed someone so relentless in developing a secure, state of the art, safe and useful product as the Shorewall firewall package for no cost or obligation involved.
SM, Germany one time more to report, that your great shorewall in the latest release 1.2.9 is working fine for me with SUSE Linux 7.3! I now have 7 machines up and running with shorewall on several versions - starting with 1.2.2 up to the new 1.2.9 and I never have encountered any problems!
SE, US You have the best support of any other package I've ever used.
Name withheld by request, Europe Because our company has information which has been classified by the national government as secret, our security doesn't stop by putting a fence around our company. Information security is a hot issue. We also make use of checkpoint firewalls, but not all of the Internet servers are guarded by checkpoint, some of them are running....Shorewall.
RM, Austria thanx for all your efforts you put into shorewall - this product stands out against a lot of commercial stuff i´ve been working with in terms of flexibility, quality & support
RG, Toronto I have never seen such a complete firewall package that is so easy to configure. I searched the Debian package system for firewall scripts and Shorewall won hands down.
RP, Guatemala My respects... I've just found and installed Shorewall 1.3.3-1 and it is a wonderful piece of software. I've just sent out an email to about 30 people recommending it. :-) While I had previously taken the time (maybe 40 hours) to really understand ipchains, then spent at least an hour per server customizing and carefully scrutinizing firewall rules, I've got shorewall running on my home firewall, with rule sets and policies that I know make sense, in under 20 minutes.
shorewall-docs-xml-4.5.21/Accounting.xml0000644000175000017500000006113412222401136020035 0ustar teastepteastep
Shorewall Traffic Accounting Tom Eastep 2003-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.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.
Accounting Basics Shorewall accounting rules are described in the file /etc/shorewall/accounting. By default, the accounting rules are placed in a chain called accounting and can thus be displayed using shorewall[-lite] show -x accounting. All traffic passing into, out of, or through the firewall traverses the accounting chain including traffic that will later be rejected by interface options such as tcpflags and maclist. The columns in the accounting file are described in shorewall-accounting (5) and shorewall6-accounting (5). In all columns except ACTION and CHAIN, the values -, any and all are treated as wild-cards. The accounting rules are evaluated in the Netfilter filter table. This is the same environment where the rules file rules are evaluated and in this environment, DNAT has already occurred in inbound packets and SNAT has not yet occurred on outbound packets. Accounting rules are not stateful -- each rule only handles traffic in one direction. For example, if eth0 is your Internet interface, and you have a web server in your DMZ connected to eth1, then to count HTTP traffic in both directions requires two rules: #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE # PORT PORT DONE - eth0 eth1 tcp 80 DONE - eth1 eth0 tcp - 80 Associating a counter with a chain allows for nice reporting. For example: #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE # PORT PORT web:COUNT - eth0 eth1 tcp 80 web:COUNT - eth1 eth0 tcp - 80 web:COUNT - eth0 eth1 tcp 443 web:COUNT - eth1 eth0 tcp - 443 DONE web Now shorewall show web (or shorewall-lite show web for Shorewall Lite users) will give you a breakdown of your web traffic: [root@gateway shorewall]# shorewall show web Shorewall-1.4.6-20030821 Chain web at gateway.shorewall.net - Wed Aug 20 09:48:56 PDT 2003 Counters reset Wed Aug 20 09:48:00 PDT 2003 Chain web (4 references) pkts bytes target prot opt in out source destination 11 1335 tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 18 1962 tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80 0 0 tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443 29 3297 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 [root@gateway shorewall]# Here is a slightly different example: #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE # PORT PORT web - eth0 eth1 tcp 80 web - eth1 eth0 tcp - 80 web - eth0 eth1 tcp 443 web - eth1 eth0 tcp - 443 COUNT web eth0 eth1 COUNT web eth1 eth0 Now shorewall show web (or shorewall-lite show web for Shorewall Lite users) simply gives you a breakdown by input and output: [root@gateway shorewall]# shorewall show accounting web Shorewall-1.4.6-20030821 Chains accounting web at gateway.shorewall.net - Wed Aug 20 10:27:21 PDT 2003 Counters reset Wed Aug 20 10:24:33 PDT 2003 Chain accounting (3 references) pkts bytes target prot opt in out source destination 8767 727K web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 0 0 web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 11506 13M web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80 0 0 web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443 Chain web (4 references) pkts bytes target prot opt in out source destination 8767 727K all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 11506 13M all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 [root@gateway shorewall]# Here's how the same example would be constructed on an HTTP server with only one interface (eth0). READ THE ABOVE CAREFULLY -- IT SAYS SERVER. If you want to account for web browsing, you have to reverse the rules below. #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE # PORT PORT web - eth0 - tcp 80 web - - eth0 tcp - 80 web - eth0 - tcp 443 web - - eth0 tcp - 443 COUNT web eth0 COUNT web - eth0 Note that with only one interface, only the SOURCE (for input rules) or the DESTINATION (for output rules) is specified in each rule. Here's the output: [root@mail shorewall]# shorewall show accounting web Shorewall-1.4.7 Chains accounting web at mail.shorewall.net - Sun Oct 12 10:27:21 PDT 2003 Counters reset Sat Oct 11 08:12:57 PDT 2003 Chain accounting (3 references) pkts bytes target prot opt in out source destination 8767 727K web tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 11506 13M web tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80 0 0 web tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 web tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443 Chain web (4 references) pkts bytes target prot opt in out source destination 8767 727K all -- eth0 * 0.0.0.0/0 0.0.0.0/0 11506 13M all -- * eth0 0.0.0.0/0 0.0.0.0/0 [root@mail shorewall]# For an example of integrating Shorewall Accounting with MRTG, see http://www.nightbrawler.com/code/shorewall-stats/.
Accounting with Bridges The structure of the accounting rules changes slightly when there are bridges defined in the Shorewall configuration. Because of the restrictions imposed by Netfilter in kernel 2.6.21 and later, output accounting rules must be segregated from forwarding and input rules. To accomplish this separation, Shorewall-perl creates two accounting chains: accounting - for input and forwarded traffic. accountout - for output traffic. If the CHAIN column contains -, then: If the SOURCE column in a rule includes the name of the firewall zone (e.g., $FW), then the default chain to insert the rule into is accountout only. Otherwise, if the DEST in the rule is any or all or 0.0.0.0/0, then the rule is added to both accounting and accountout. Otherwise, the rule is added to accounting only.
Sectioned Accounting Rules Traditionally, the root of the Shorewall accounting rules has been the accounting chain. Having a single root chain has drawbacks: Many rules are traversed needlessly (they could not possibly match traffic). At any time, the Netfilter team could begin generating errors when loading those same rules. MAC addresses may not be used in the accounting rules. The accounting chain cannot be optimized when OPTIMIZE_ACCOUNTING=Yes. The rules may be defined in any order so the rules compiler must post-process the ruleset to ensure that there are no loops and to alert the user to unreferenced chains. Beginning with Shorewall 4.4.18, the accounting structure can be created with three root chains: accountin: Rules that are valid in the INPUT chain (may not specify an output interface). accountout: Rules that are valid in the OUTPUT chain (may not specify an input interface or a MAC address). accounting: Other rules. The new structure is enabled by sectioning the accounting file in a manner similar to the rules file. The sections are INPUT, OUTPUT and FORWARD and must appear in that order (although any of them may be omitted). The first non-commentary record in the accounting file must be a section header when sectioning is used. Beginning with Shorewall 4.4.20, the ACCOUNTING_TABLE setting was added to shorewall.conf and shorewall6.conf. That setting determines the Netfilter table (filter or mangle) where the accounting rules are added. When ACCOUNTING_TABLE=mangle is specified, the available sections are PREROUTING, INPUT, OUTPUT, FORWARD and POSTROUTING. Section headers have the form: section-name When sections are enabled: You must jump to a user-defined accounting chain before you can add rules to that chain. This eliminates loops and unreferenced chains. You may not specify an output interface in the PREROUTING and INPUT sections. In the OUTPUT and POSTROUTING sections: You may not specify an input interface You may not jump to a chain defined in the INPUT or PREROUTING sections that specifies an input interface You may not specify a MAC address You may not jump to a chain defined in the INPUT or PREROUTING section that specifies a MAC address. The default value of the CHAIN column is: accountin in the INPUT section accounout in the OUTPUT section accountfwd in the FORWARD section accountpre in the PREROUTING section accountpost in the POSTROUTING section Traffic addressed to the firewall goes through the rules defined in the INPUT section. Traffic originating on the firewall goes through the rules defined in the OUTPUT section. Traffic being forwarded through the firewall goes through the rules from the FORWARD sections. Here is a sample sectioned file that used Per-IP Accounting. In this example, the dmz net corresponds to a vserver zone so lives on the firewall itself. #ACTION CHAIN SOURCE DESTINATION PROTO DEST SOURCE USER/ MARK IPSEC # PORT(S) PORT(S) GROUP SECTION INPUT ACCOUNT(fw-net,$FW_NET) - COM_IF ACCOUNT(dmz-net,$DMZ_NET) - COM_IF SECTION OUTPUT ACCOUNT(fw-net,$FW_NET) - - COM_IF ACCOUNT(dmz-net,$DMZ_NET) - - COM_IF SECTION FORWARD ACCOUNT(loc-net,$INT_NET) - COM_IF INT_IF ACCOUNT(loc-net,$INT_NET) - INT_IF COM_IF
Integrating Shorewall Accounting with Collectd Sergiusz Pawlowicz has written a nice article that shows how to integrate Shorewall Accounting with collectd to produce nice graphs of traffic activity. The article may be found at http://collectd.org/wiki/index.php/Plugin:IPTables.
Per-IP Accounting Shorewall 4.4.17 added support for per-IP accounting using the ACCOUNT target. That target is only available when xtables-addons is installed. This support has been successfully tested with xtables-addons 1.32 on: Fedora 14 Debian Squeeze OpenSuSE 11.3 and xtables-addons Version 1.21 on: Debian Lenny Information about xtables-addons installation may be found at here. Per-IP accounting is configured in shorewall-accounting (5) (it is currently not supported in IPv6). In the ACTION column, enter: ACCOUNT(table,network) where table is the name of an accounting table (you choose the name). All rules specifying the same table will have their per-IP counters accumulated in that table. network is an IPv4 network in CIDR notation. The network can be as large as a /8 (class A). One nice feature of per-IP accounting is that the counters survive shorewall restart. This has a downside, however. If you change the network associated with an accounting table, then you must shorewall stop; shorewall start to have a successful restart (counters will be cleared). Example: Suppose your WAN interface is eth0 and your LAN interface is eth1 with network 172.20.1.0/24. To account for all traffic between the WAN and LAN interfaces: #ACTION CHAIN SOURCE DEST ... ACCOUNT(net-loc,172.20.1.0/24) - eth0 eth1 ACCOUNT(net-loc,172.20.1.0/24) - eth1 eth0 This will create a net-loc table for counting packets and bytes for traffic between the two interfaces. The table is dumped using the iptaccount utility (part of xtables-addons): iptaccount [-f] -l net-loc Example: gateway:~# iptaccount -l net-loc libxt_ACCOUNT_cl userspace accounting tool v1.3 Showing table: net-loc Run #0 - 3 items found IP: 172.20.1.105 SRC packets: 115 bytes: 131107 DST packets: 68 bytes: 20045 IP: 172.20.1.131 SRC packets: 47 bytes: 12729 DST packets: 38 bytes: 25304 IP: 172.20.1.145 SRC packets: 20747 bytes: 2779676 DST packets: 27050 bytes: 32286071 Finished. gateway:~# For each local IP address with non-zero counters, the packet and byte count for both incoming traffic (IP is DST) and outgoing traffic (IP is SRC) are listed. The -f option causes the table to be flushed (reset all counters to zero) after printing. For a command synopsis: iptaccount --help /sbin/shorewall also supports a show ipa command (from my own gateway just after I flushed the counters using iptaccount -f -l.: gateway:~# shorewall show ipa Shorewall 4.4.18-Beta1 per-IP Accounting at gateway - Thu Feb 10 13:28:37 PST 2011 Showing table: loc-net IP: 172.20.1.146 SRC packets: 9 bytes: 574 DST packets: 9 bytes: 770 Showing table: dmz-net IP: 70.90.191.124 SRC packets: 243 bytes: 23726 DST packets: 248 bytes: 39036 IP: 70.90.191.125 SRC packets: 73 bytes: 10640 DST packets: 73 bytes: 4846 Showing table: fw-net IP: 70.90.191.121 SRC packets: 0 bytes: 0 DST packets: 4 bytes: 243 IP: 70.90.191.122 SRC packets: 11 bytes: 1338 DST packets: 8 bytes: 5465 IP: 70.90.191.123 SRC packets: 42 bytes: 4604 DST packets: 44 bytes: 10662 gateway:~#
Accounting using nfacct Beginning with the 3.3 kernels, Netfilter supports a form of accounting (nfacct) that is triggered by iptables rules but that survives purging and/or reloading the Netfilter ruleset. Shorewall support for this form of accounting was added in Shorewall 4.5.7. As of this writing (late July 2012), Fedora 17 has partial support for this feature but not all. It is necessary to download and build the following: libnetfilter_acct nfacct The following Fedora packages are also required: libnetlink and libnetlink-dev libmnl and libmnl-dev The tarballs are available from the Netfilter download sites. The nfacct utility can create, delete and display nfacct objects. These named objects consist of a packet and byte counter. Packets matching those netfilter rules that use the nfacct match cause the packet and byte count in the object named in the match to be incremented. To use nfaccnt with Shorewall, use the NFACCT target. See shorewall-accounting(5) for details. The shorewall show nfacct command is a thin wrapper around the nfacct list command.
shorewall-docs-xml-4.5.21/blacklisting_support_ru.xml0000644000175000017500000003005512222401136022711 0ustar teastepteastep
Чёрные списки в 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-4.5.21/ManualChains.xml0000644000175000017500000001712412222401136020306 0ustar teastepteastep
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 DEST PORT(S) 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 DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST DNAT- net loc: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 DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST DNAT- net loc: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-4.5.21/IPSEC.xml0000644000175000017500000004067012222401136016610 0ustar teastepteastep
IPSEC Tunnels 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. The information in this article is only applicable if you plan to have IPSEC end-points on the same system where Shorewall is used. This documentation is incomplete regarding using IPSEC and the 2.6 Kernel. Netfilter currently lacks full support for the 2.6 kernel's implementation of IPSEC. Until that implementation is complete, only a simple network-network tunnel is described for 2.6. UPDATE: Some distributions such as SUSE are now shipping Kernels and iptables with the IPSEC-Netfilter patches and policy match support. Check this article for information concerning this support and Shorewall.
Preliminary Reading I recommend reading the VPN Basics article if you plan to implement any type of VPN.
Configuring FreeS/Wan and Derivatives Such as OpenS/Wan There is an excellent guide to configuring IPSEC tunnels at http://jixen.tripod.com/. I highly recommend that you consult that site for information about configuring FreeS/Wan. The documentation below assumes that you have disabled opportunistic encryption feature in FreeS/Wan 2.0 using the following additional entries in ipsec.conf: conn block auto=ignore conn private auto=ignore conn private-or-clear auto=ignore conn clear-or-private auto=ignore conn clear auto=ignore conn packetdefault auto=ignore For further information see http://www.freeswan.org/freeswan_trees/freeswan-2.03/doc/policygroups.html.
IPSec Gateway on the Firewall System Suppose that we have the following situation: We want systems in the 192.168.1.0/24 sub-network to be able to communicate with systems in the 10.0.0.0/8 network. We assume that on both systems A and B, eth0 is the Internet interface. To make this work, we need to do two things: Open the firewall so that the IPSEC tunnel can be established (allow the ESP and AH protocols and UDP Port 500). Allow traffic through the tunnel. Opening the firewall for the IPSEC tunnel is accomplished by adding an entry to the /etc/shorewall/tunnels file. In /etc/shorewall/tunnels on system A, we need the following #TYPE ZONE GATEWAY GATEWAY ZONE ipsec net 134.28.54.2 In /etc/shorewall/tunnels on system B, we would have: #TYPE ZONE GATEWAY GATEWAY ZONE ipsec net 206.161.148.9 If either of the endpoints is behind a NAT gateway then the tunnels file entry on the other endpoint should specify a tunnel type of ipsecnat rather than ipsec and the GATEWAY address should specify the external address of the NAT gateway. You need to define a zone for the remote subnet or include it in your local zone. In this example, we'll assume that you have created a zone called vpn to represent the remote subnet. Note that you should define the vpn zone before the net zone. /etc/shorewall/zones (both systems): #ZONE TYPE OPTIONS vpn ipv4 net ipv4 If you are running kernel 2.4:
At both systems, ipsec0 would be included in /etc/shorewall/interfaces as a vpn interface: #ZONE INTERFACE BROADCAST OPTIONS vpn ipsec0
If you are running kernel 2.6:
It is essential that the vpn zone be declared before the net zone in /etc/shorewall/zones. Remember the assumption that both systems A and B have eth0 as their Internet interface. You must define the vpn zone using the /etc/shorewall/hosts file. /etc/shorewall/hosts - System A #ZONE HOSTS OPTIONS vpn eth0:10.0.0.0/8 /etc/shorewall/hots - System B #ZONE HOSTS OPTIONS vpn eth0:192.168.1.0/24 In addition, if you are using Masquerading or SNAT on your firewalls, you need to eliminate the remote network from Masquerade/SNAT. These entries replace your current masquerade/SNAT entries for the local networks. /etc/shorewall/masq - System A #INTERFACE SUBNET ADDRESS eth0:!10.0.0.0/8 192.168.1.0/24 /etc/shorewall/masq - System B #INTERFACE SUBNET ADDRESS eth0:!192.168.1.0/24 10.0.0.0/8
You will need to allow traffic between the vpn zone and the loc zone -- 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 Once you have these entries in place, restart Shorewall (type shorewall restart); you are now ready to configure the tunnel in FreeS/WAN.
VPN Hub using Kernel 2.4 Shorewall can be used in a VPN Hub environment where multiple remote networks are connected to a gateway running Shorewall. This environment is shown in this diagram. We want systems in the 192.168.1.0/24 sub-network to be able to communicate with systems in the 10.0.0.0/16 and 10.1.0.0/16 networks and we want the 10.0.0.0/16 and 10.1.0.0/16 networks to be able to communicate. To make this work, we need to do several things: Open the firewall so that two IPSEC tunnels can be established (allow the ESP and AH protocols and UDP Port 500). Allow traffic through the tunnels two/from the local zone (192.168.1.0/24). Deny traffic through the tunnels between the two remote networks. Opening the firewall for the IPSEC tunnels is accomplished by adding two entries to the /etc/shorewall/tunnels file. In /etc/shorewall/tunnels on system A, we need the following #TYPE ZONE GATEWAY GATEWAY ZONE ipsec net 134.28.54.2 ipsec net 130.252.100.14 In /etc/shorewall/tunnels on systems B and C, we would have: #TYPE ZONE GATEWAY GATEWAY ZONE ipsec net 206.161.148.9 If either of the endpoints is behind a NAT gateway then the tunnels file entry on the other endpoint should specify a tunnel type of ipsecnat rather than ipsec and the GATEWAY address should specify the external address of the NAT gateway. On each system, we will create a zone to represent the remote networks. On System A: #ZONE TYPE OPTIONS vpn1 ipv4 vp2 ipv4 On systems B and C: #ZONE TYPE OPTIONS vpn ipv4 At system A, ipsec0 represents two zones so we have the following in /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS - ipsec0 The /etc/shorewall/hosts file on system A defines the two VPN zones: #ZONE HOSTS OPTIONS vpn1 ipsec0:10.0.0.0/16 vpn2 ipsec0:10.1.0.0/16 At systems B and C, ipsec0 represents a single zone so we have the following in /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS vpn ipsec0 On systems A, you will need to allow traffic between the vpn1 zone and the loc zone as well as between vpn2 and the loc zone -- if you simply want to admit all traffic in both directions, you can use the following policy file entries on all three gateways: #SOURCE DEST POLICY LOG LEVEL loc vpn1 ACCEPT vpn1 loc ACCEPT loc vpn2 ACCEPT vpn2 loc ACCEPT On systems B and C, you will need to allow traffic between the vpn zone and the loc zone -- if you simply want to admit all traffic in both directions, you can use the following policy file entries on all three gateways: /etc/shorewall/policy -- Systems B & C #SOURCE DEST POLICY LOG LEVEL loc vpn ACCEPT vpn loc ACCEPT Once you have the Shorewall entries added, restart Shorewall on each gateway (type shorewall restart); you are now ready to configure the tunnels in FreeS/WAN. to allow traffic between the networks attached to systems B and C, it is necessary to simply add two additional entries to the /etc/shorewall/policy file on system A. #SOURCE DEST POLICY LOG LEVEL vpn1 vpn2 ACCEPT vpn2 vpn1 ACCEPT If you find traffic being rejected/dropped in the OUTPUT chain, place the names of the remote VPN zones as a comma-separated list in the GATEWAY ZONE column of the /etc/shorewall/tunnels file entry.
Mobile System (Road Warrior) Using Kernel 2.4 Suppose that you have a laptop system (B) that you take with you when you travel and you want to be able to establish a secure connection back to your local network. Road Warrior VPN You need to define a zone for the laptop or include it in your local zone. In this example, we'll assume that you have created a zone called vpn to represent the remote host. /etc/shorewall/zones - System A #ZONE TYPE OPTIONS vpn ipv4 In this instance, the mobile system (B) has IP address 134.28.54.2 but that cannot be determined in advance. In the /etc/shorewall/tunnels file on system A, the following entry should be made: #TYPE ZONE GATEWAY GATEWAY ZONE ipsec net 0.0.0.0/0 the GATEWAY ZONE column contains the name of the zone corresponding to peer subnetworks. This indicates that the gateway system itself comprises the peer subnetwork; in other words, the remote gateway is a standalone system. You will need to configure /etc/shorewall/interfaces and establish your through the tunnel policy as shown under the first example above.
Dynamic RoadWarrior Zones Beginning with Shorewall release 1.3.10, you can define multiple VPN zones and add and delete remote endpoints dynamically using /sbin/shorewall. With Shorewall 2.0.2 Beta 1 and later versions, this capability must be enabled by setting DYNAMIC_ZONES=Yes in shorewall.conf. DYNAMIC_ZONES=Yes is not supported by Shorewall-perl 4.2.0 or later versions. Use dynamic zones defined by ipsets instead. In /etc/shorewall/zones: #ZONE TYPE OPTIONS vpn1 ipv4 vpn2 ipv4 vpn3 ipv4 In /etc/shorewall/tunnels: #TYPE ZONE GATEWAY GATEWAY ZONE ipsec net 0.0.0.0/0 vpn1,vpn2,vpn3 When Shorewall is started, the zones vpn[1-3] will all be empty and Shorewall will issue warnings to that effect. These warnings may be safely ignored. FreeS/Wan may now be configured to have three different Road Warrior connections with the choice of connection being based on X-509 certificates or some other means. Each of these connections will utilize a different updown script that adds the remote station to the appropriate zone when the connection comes up and that deletes the remote station when the connection comes down. For example, when 134.28.54.2 connects for the vpn2 zone the up part of the script will issue the command: /sbin/shorewall add ipsec0:134.28.54.2 vpn2 and the down part will: /sbin/shorewall delete ipsec0:134.28.54.2 vpn2
shorewall-docs-xml-4.5.21/PacketMarking.xml0000644000175000017500000007103112222401136020460 0ustar teastepteastep
Packet Marking using /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.
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 tcrules file 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 tcrules 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/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/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, PORT(S), CLIENT PORT(S_, 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 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/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/tcrules file. #ACTION SOURCE DEST PROTO PORT(S) CLIENT USER TEST LENGTH TOS # PORT(S) 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request #Rule 1 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply #Rule 2 1 $FW 0.0.0.0/0 icmp echo-request #Rule 3 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 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 ##LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE 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 tcrules 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 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE Here is /etc/shorewall/tcrules: #ACTION SOURCE DEST PROTO PORT(S) CLIENT USER TEST # PORT(S) 1:110 192.168.0.0/22 eth3 #Our internal nets get priority #over the server 1:130 206.124.146.177 eth3 tcp - 873 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE And here is /etc/shorewall/tcdevices and /etc/shorewall/tcclasses: #INTERFACE IN-BANDWITH OUT-BANDWIDTH eth3 1.3mbit 384kbit #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE #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 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE 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/tcrules 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-4.5.21/VPNBasics.xml0000644000175000017500000003543712222401136017542 0ustar teastepteastep
VPN, Netfilter and Shorewall — The Basics 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.
Gateway-to-gateway traffic vs. Host-to-host traffic. The purpose of a Virtual Private Network (VPN) is to provide for secure communication between a set of hosts. Communication between a pair of hosts connected by a VPN occurs in stages: Local-host-to-local-gateway. This communication is not encrypted; in the case where the traffic originates on the gateway itself, the communication is local to that system. Local-gateway-to-remote-gateway. This communication is encrypted and can use a tunneling protocol such as GRE, AH or ESP or a standard protocol such as UDP or TCP. Some VPNs use multiple protocols; for example PPTP uses TCP port 1723 and GRE while IPSEC uses UDP port 500 together with ESP or AH. Remote-gateway-to-remote-host. This is just the unencrypted traffic described in the first item as it is delivered to its destination. Of course, one-way communication generally isn't useful so we need traffic in the other direction as well. Remote-host-to-remote-gateway. Remote-gateway-to-local-gateway. Local-gateway-to-local-host.
Relationship to Netfilter When Netfilter is configured on a VPN gateway, each VPN packet goes through Netfilter twice! Let's first consider outbound traffic: Local-host-to-local-gateway. This traffic has a source address in the local network or on the gateway itself. The destination IP address is that of a remote host; either the remote gateway itself or a host behind that gateway. Local-gateway-to-remote-gateway. This (encrypted) traffic has a source IP address on the gateway and is addressed to the remote gateway. Incoming traffic is similar.
What does this mean with Shorewall? When Shorewall is installed on a VPN gateway system, it categorizes the VPN-related traffic slightly differently: Local-host-to-remote-host — same as Local-host-to-local-gateway above. Local-gateway-to-remote-gateway. Remote-gateway-to-local-gateway. Remote-host-to-local-host — same as Local-gateway-to-local-host above. Shorewall implements a set of features for dealing with VPN. The /etc/shorewall/tunnels file. This file is used to define remote gateways and the type of encrypted traffic that will be passed between the Shorewall system and those remote gateways. In other words, the tunnels file deals with Local-gateway-to-remote-gateway and Remote-gateway-to-local-gateway traffic. The /etc/shorewall/zones file. An entry in this file allows you to associated a name with the set of hosts behind the remote gateway (or to the remote gateway itself if it is a standalone system). The /etc/shorewall/interfaces and /etc/shorewall/hosts files. These files are used to associate a set of remote hosts with the zone name defined in /etc/shorewall/zones. The /etc/shorewall/policy and /etc/shorewall/rules files. These files are used to define the connections that are permitted between the remote and local hosts -- in other words, the Local-host-to-remote-host and Remote-host-to-local-host traffic.
Defining Remote Zones Most VPN types are implemented using a virtual network device such as pppN (e.g., ppp0), tunN (e.g., tun0), etc. This means that in most cases, remote zone definition is similar to zones that you have already defined. /etc/shorewall/zones: #ZONE TYPE fw firewall net ipv4 loc ipv4 rem ipv4 /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTION net eth0 - tcpflags,routefilter loc eth1 - rem ppp0 -
Allowing Traffic Normally, you will just allow all traffic between your remote client(s) and the local zone. You can do that with a couple of policies: #SOURCE DESTINATION POLICY LEVEL BURST/LIMIT rem loc ACCEPT loc rem ACCEPT Similar policies using $FW rather than 'loc' can permit traffic from the remote clients to/from the firewall.
Different Firewall Policies for Different Remote Systems The /etc/shorewall/hosts file comes into play when: You have a number of remote networks. The remote networks have different firewall requirements and you want to divide them into multiple zones. There is no fixed relationship between the remote networks and virtual network devices (for example, the VPN uses PPTP and remote gateways connect on demand). In this case, your configuration takes the following approach: etc/shorewall/zones: #ZONE TYPE OPTIONS net ipv4 loc ipv4 rem1 ipv4 #Remote LAN 1 rem2 ipv4 #Remote LAN 2 /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTION net eth0 - tcpflags,routefilter loc eth1 - - tun+ - /etc/shorewall/hosts: #ZONE HOST(S) OPTIONS rem1 tun+:10.0.0.0/24 rem2 tun+:10.0.1.0/24 The /etc/shorewall/hosts file is also used with kernel 2.6 native IPSEC.
Eliminating the /etc/shorewall/tunnels file The /etc/shorewall/tunnels file provides no functionality that could not be implemented using entries in /etc/shorewall/rules and I have elimination of the /etc/shorewall/tunnels file as a long-term goal. The following sections show how entries in /etc/shorewall/tunnels can be replaced by rules for some common tunnel types.
IPSEC /etc/shorewall/tunnels:
#TYPE ZONE GATEWAY GATEWAY ZONE ipsec Z1 1.2.3.4 Z2
/etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST SOURCE # PORT PORT(S) ACCEPT $FW Z1:1.2.3.4 udp 500 ACCEPT Z1:1.2.3.4 $FW udp 500 ACCEPT $FW Z1:1.2.3.4 50 ACCEPT Z1:1.2.3.4 $FW 50 ACCEPT $FW Z1:1.2.3.4 51 ACCEPT Z1:1.2.3.4 $FW 51 ACCEPT $FW Z2:1.2.3.4 udp 500 ACCEPT Z2:1.2.3.4 $FW udp 500
The "noah" option causes the rules for protocol 51 to be eliminated. The "ipsecnat" causes UDP port 4500 to be accepted in both directions. If no GATEWAY ZONE is given then the last two rules above are omitted.
PPTP /etc/shorewall/tunnels:
#TYPE ZONE GATEWAY GATEWAY ZONE pptpserver Z1 1.2.3.4
/etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST SOURCE # PORT PORT(S) ACCEPT Z1:1.2.3.4 $FW tcp 1723 ACCEPT $FW Z1:1.2.3.4 47 ACCEPT Z1:1.2.3.4 $FW 47
Tunnel type "pptpclient" simply reverses the direction of the tcp port 1723 rule.
OpenVPN /etc/shorewall/tunnels:
#TYPE ZONE GATEWAY GATEWAY ZONE openvpn:port Z1 1.2.3.4
/etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST SOURCE # PORT PORT(S) ACCEPT Z1:1.2.3.4 $FW udp port ACCEPT $FW Z1:1.2.3.4 udp port
/etc/shorewall/tunnels:
#TYPE ZONE GATEWAY GATEWAY ZONE openvpnclient:port Z1 1.2.3.4
/etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST SOURCE # PORT PORT(S) ACCEPT Z1:1.2.3.4 $FW udp - port ACCEPT $FW Z1:1.2.3.4 udp port
/etc/shorewall/tunnels:
#TYPE ZONE GATEWAY GATEWAY ZONE openvpnserver:port Z1 1.2.3.4
/etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST SOURCE # PORT PORT(S) ACCEPT Z1:1.2.3.4 $FW udp port ACCEPT $FW Z1:1.2.3.4 udp - port
Links to Other VPN Articles at shorewall.net OpenVPN IPSEC PPTP
shorewall-docs-xml-4.5.21/Shorewall-Lite.xml0000644000175000017500000010077712222401136020605 0ustar teastepteastep
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 routestopped 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 routestopped 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 routestopped 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-4.5.21/standalone.xml0000644000175000017500000007212712222401136020077 0ustar teastepteastep
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 ZONE DESTINATION ZONE POLICY LOG LEVEL LIMIT:BURST $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 /etc/shorewall/macro.*, the general format of a rule in /etc/shorewall/rules is: #ACTION SOURCE DESTINATION PROTO DEST PORT(S) <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 DESTINATION PROTO DEST PORT(S) Web(ACCEPT) net $FW IMAP(ACCEPT)net $FW 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 DESTINATION PROTO DEST PORT(S) ACCEPT net $FW <protocol> <port> You want to run a Web Server and a IMAP Server on your firewall system: #ACTION SOURCE DESTINATION PROTO DEST PORT(S) 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 DEST PORT(S) 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, routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A running firewall may be restarted using the shorewall restart 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 added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. Also, I don't recommend using shorewall restart; 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-4.5.21/Shorewall_Squid_Usage.xml0000644000175000017500000004514512222401136022200 0ustar teastepteastep
Using Shorewall with Squid Tom Eastep 2003-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 . This page covers Shorewall configuration to use with Squid running as a Transparent Proxy or as a Manual Proxy. 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.
Squid as a Transparent (Interception) Proxy This section gives instructions for transparent proxying of HTTP. HTTPS (normally TCP port 443) cannot be proxied transparently (stop and think about it for a minute; if HTTPS could be transparently proxied, then how secure would it be?). Please observe the following general requirements: In all cases, Squid should be configured to run as a transparent proxy as described at http://wiki.squid-cache.org/SquidFaq/InterceptionProxy. The bottom line of that article is that if you are running Squid 2.6 or later, then you simply need to add the word transparent to your http_port specification: http_port 3128 transparent In earlier Squid versions, you need to set several options: http_port 3128 httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on Depending on your distribution, other Squid configuration changes may be required. These changes typically consist of: Adding an ACL that represents the clients on your local network. Example: ACL my_networks src 192.168.1.0/24 192.168.2.0/24 Allowing HTTP access to that ACL. Example: http_access allow my_networks See your distribution's Squid documentation and http://www.squid-cache.org/ for details. It is a good idea to get Squid working as a manual proxy first before you try transparent proxying. The following instructions mention the file /etc/shorewall/start - if you don't have that file, simply create it. When the Squid server is in the local zone, that zone must be defined ONLY by its interface -- no /etc/shorewall/hosts file entries. That is because the packets being routed to the Squid server still have their original destination IP addresses. You must have iptables installed on your Squid server. In the instructions below, only TCP Port 80 is opened from the system running Squid to the Internet. If your users require browsing sites that use a port other than 80 (e.g., http://www.domain.tld:8080) then you must open those ports as well.
Configurations Three different configurations are covered: Squid (transparent) Running on the Firewall Squid (transparent) Running in the local Network Squid (transparent) Running in a DMZ
Squid (transparent) Running on the Firewall You want to redirect all local www connection requests EXCEPT those to your own http server (206.124.146.177) to a Squid transparent proxy running on the firewall and listening on port 3128. Squid will of course require access to remote web servers. In /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST ACCEPT $FW net tcp www REDIRECT loc 3128 tcp www - !206.124.146.177 There may be a requirement to exclude additional destination hosts or networks from being redirected. For example, you might also want requests destined for 130.252.100.0/24 to not be routed to Squid. If needed, you may just add the additional hosts/networks to the ORIGINAL DEST column in your REDIRECT rule. /etc/shorewall/rules:#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST REDIRECT loc 3128 tcp www - !206.124.146.177,130.252.100.0/24 People frequently ask How can I exclude certain internal systems from using the proxy? I want to allow those systems to go directly to the net. Suppose that you want to exclude 192.168.1.5 and 192.168.1.33 from the proxy. Your rules would then be: #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST ACCEPT $FW net tcp www REDIRECT loc:!192.168.1.5,192.168.1.33\ 3128 tcp www - !206.124.146.177,130.252.100.0/24 ACCEPT loc net tcp www The last rule may be omitted if your loc->net policy is ACCEPT. In some cases (when running an LTSP server on the Shorewall system), you might want to transparently proxy web connections that originate on the firewall itself. This requires care to ensure that Squid's own web connections are not proxied. First, determine the user id that Squid is running under: gateway:/etc/shorewall# ps aux | fgrep -i squid | fgrep -v fgrep root 10085 0.0 0.0 23864 700 ? Ss Apr22 0:00 /usr/sbin/squid -D -YC proxy 10088 0.0 0.9 40512 19192 ? S Apr22 10:58 (squid) -D -YC gateway:/etc/shorewall# In this case, the proxy process (squid) is running under the proxy user Id. We add these rules: #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL RATE USER/ # PORT(S) DEST LIMIT GROUP ACCEPT $FW net tcp www REDIRECT $FW 3128 tcp www - - - !proxy
Squid (transparent) Running in the local network You want to redirect all local www connection requests to a Squid transparent proxy running in your local zone at 192.168.1.3 and listening on port 3128. Your local interface is eth1. There may also be a web server running on 192.168.1.3. It is assumed that web access is already enabled from the local zone to the Internet. Add this entry to your /etc/shorewall/providers file. #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS Squid 1 202 - eth1 192.168.1.3 loose,notrack In /etc/shorewall/tcrules add: #MARK SOURCE DEST PROTO DEST # PORT(S) 202:P eth1:!192.168.1.3 0.0.0.0/0 tcp 80 In /etc/shorewall/interfaces : #ZONE INTERFACE BROADCAST OPTIONS loc eth1 detect routeback,routefilter=0,logmartians=0 On 192.168.1.3, arrange for the following command to be executed after networking has come up iptables -t nat -A PREROUTING -i eth0 ! -d 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128 If you are running RedHat on the server, you can simply execute the following commands after you have typed the iptables command above: iptables-save > /etc/sysconfig/iptables chkconfig --level 35 iptables on
Squid (transparent) Running in the DMZ You have a single system in your DMZ with IP address 192.0.2.177. You want to run both a web server and Squid on that system.
Simple Configuration In /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST DNAT loc dmz:192.0.2.177:3128 tcp 80 - !192.0.2.177
More Complex configuration Assume that the dmz is connected through eth2 and that your local lan interfaces through eth1 Add this entry to your /etc/shorewall/providers file. #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS Squid 1 202 - eth2 192.0.2.177 loose,notrack In /etc/shorewall/tcrules add: #MARK SOURCE DEST PROTO DEST # PORT(S) 202:P eth1 0.0.0.0/0 tcp 80 In /etc/shorewall/interfaces : #ZONE INTERFACE BROADCAST OPTIONS loc eth2 detect routefilter=0,logmartians=0 On 172.0.2.177, arrange for the following command to be executed after networking has come up iptables -t nat -A PREROUTING -i eth0 ! -d 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128 If you are running RedHat on the server, you can simply execute the following commands after you have typed the iptables command above: iptables-save > /etc/sysconfig/iptables chkconfig --level 35 iptables on
Squid as a Manual Proxy Assume that Squid is running in zone SZ and listening on port SP; all web sites that are to be accessed through Squid are in the net zone. Then for each zone Z that needs access to the Squid server. /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT Z SZ tcp SP ACCEPT SZ net tcp 80,443 Squid on the firewall listening on port 8080 with access from the <quote>loc</quote> zone: /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT loc $FW tcp 8080 ACCEPT $FW net tcp 80,443
Squid3 as a Transparent Proxy with TPROXY Shorewall 4.5.4 contains support for TPROXY. TPROXY differs from REDIRECT in that it does not modify the IP header and requires Squid 3 or later. Because the IP header stays intact, TPROXY requires policy routing to direct the packets to the proxy server running on the firewall. This approach requires TPROXY support in your kernel and iptables and Squid 3. See http://wiki.squid-cache.org/Features/Tproxy4. Support for the TPROXY action in shorewall-tcrules(5) and the option in shorewall-providers(5) has been available since Shoreall 4.4.7. That support required additional rules to be added in the 'start' extention script to make it work reliably. The following configuration works with Squid running on the firewall itself (assume that Squid is listening on port 3129 for TPROXY connections). /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS - lo - - /etc/shorewall/providers: #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY Tproxy 1 - - lo - tproxy Notice that the MARK, DUPLICATE and GATEWAY columns are empty and that the only option is . /etc/shorewall/tcrules (assume loc interface is eth1 and net interface is eth0): FORMAT 2 #MARK SOURCE DEST PROTO DEST SOURCE # PORT(S) PORT(S) DIVERT eth0 0.0.0.0/0 tcp - 80 TPROXY(3129) eth1 0.0.0.0/0 tcp 80 The DIVERT rules are used to avoid unnecessary invocation of TPROXY for request packets after the connection is established and to direct response packets back to Squid3. If you run a web server on the Shorewall system that also listens on port 80, then you need to exclude it from TPROXY. Suppose that your web server listens on 192.0.2.144; then: FORMAT 2 #MARK SOURCE DEST PROTO DEST SOURCE # PORT(S) PORT(S) DIVERT eth0 0.0.0.0/0 tcp - 80 TPROXY(3129) eth1 !192.0.2.144 tcp 80 - /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT loc $FW tcp 80 ACCEPT $FW net tcp 80 /etc/squid3/squid.conf: ... http_port 3129 tproxy ... If you use TPROXY with both IPv4 and IPv6, then both your local hosts and the gateway must have the same DNS view. If a client resolves a website URL to an IPv6 address and the server can only resolve to an IPv4 address, then Squid will attempt to connect to the IPv4 address using the local client's IPv6 address. That clearly doesn't work.
shorewall-docs-xml-4.5.21/three-interface.xml0000644000175000017500000015552712222401136021022 0ustar teastepteastep
Three-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 with DMZ 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 one of its more popular configurations: 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. DMZ connected to a separate Ethernet interface. The purpose of a DMZ is to isolate those servers that are exposed to the Internet from your local systems so that if one of those servers is compromised there is still a firewall between the hacked server and your local systems. Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up, ... Here is a schematic of a typical installation.
schematic of a typical installation
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 first read through the guide 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 will only need to deal with a few of these as described in this guide. After you have installed Shorewall, locate the three-interface Sample configuration: If you installed using an RPM, the samples will be in the Samples/three-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 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/masq /usr/share/doc/packages/shorewall/Samples/three-interfaces/policy /usr/share/doc/packages/shorewall/Samples/three-interfaces/routestopped /usr/share/doc/packages/shorewall/Samples/three-interfaces/rules /usr/share/doc/packages/shorewall/Samples/three-interfaces/zones ~# If you installed using the tarball, the samples are in the Samples/three-interfaces directory in the tarball. If you installed using a Shorewall 3.x .deb, the samples are in /usr/share/doc/shorewall/examples/three-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/three-interfaces. You do not need the shorewall-doc package to have access to the samples. Note to Debian Users If you install using the .deb, you will find that your /etc/shorewall directory is 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 three-interface sample configuration, the following zone names are used: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 loc ipv4 dmz ipv4Zone names 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, he name of the firewall zone is stored in the shell variable $FW which may be used throughout the Shorewall configuration to refer to the firewall zone. 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 three-interface sample has the following policies: #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT net all DROP info all all REJECT info In the three-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 LOG LEVEL LIMIT:BURST $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. 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 LOG LEVEL LIMIT:BURST loc $FW ACCEPT $FW loc ACCEPT 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. At this point, edit your /etc/shorewall/policy file and make any changes that you wish.
Network Interfaces
DMZ
The firewall has three 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 using ISDN, you 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 Local Interface will be an Ethernet adapter (eth0, eth1 or eth2) and will be connected to a hub or switch. Your local computers will be connected to the same switch (note: If you have only a single local system, you can connect the firewall directly to the computer using a cross-over cable). Your DMZ Interface will also be an Ethernet adapter (eth0, eth1 or eth2) and will be connected to a hub or switch. Your DMZ computers will be connected to the same switch (note: If you have only a single DMZ system, you can connect the firewall directly to the computer using a cross-over cable). Do NOT connect multiple interfaces 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 and DMZ interfaces. Your firewall should have exactly one default route via your ISP's Router. The Shorewall three-interface sample configuration assumes that the external interface is eth0, the local interface is eth1 and the DMZ interface is eth2. 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 - (without 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 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. Regardless of how the 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 for your internal network (the local and DMZ Interfaces 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.255 You will want to assign your local addresses from one sub-network or subnet and your DMZ addresses from another 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 1 bits from the left of the subnet mask. Example sub-network 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 (Local Computers 1 & 2) should be configured with their default gateway set to the IP address of the firewall's internal interface and your DMZ computers (DMZ Computers 1 & 2) should be configured with their default gateway set to the IP address of the firewall's DMZ 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. The remainder of this guide will assume that you have configured your network as shown here:
DMZ The default gateway for the DMZ computers would be 10.10.11.254 and the default gateway for the Local computers 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 and if it is in the 10.10.11.0/24 subnet then you will need to select a different RFC 1918 subnet for your DMZ.
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 local computer 1) 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 look 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). When the firewall receives a return packet, it rewrites the destination address back to 10.10.10.1 and forwards the packet on to local computer 1. On Linux systems, the above process is often referred to as IP Masquerading and 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. If your external firewall interface is eth0 then you do not need to modify the file provided with the sample. Otherwise, edit /etc/shorewall/masq and change it to match your configuration. If, in spite of all advice to the contrary, you are using this guide and want to use one-to-one NAT or Proxy ARP for your DMZ, you will need to modify the SOURCE column to list just your local interface (10.10.10.0/24 in the above example). If your external IP is static, you can enter it 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. Entering your static IP in column 3 makes processing outgoing packets a little more efficient. 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 will be to run one or more servers on your DMZ 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 your 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. The general form of a simple port forwarding rule in /etc/shorewall/rules is: #ACTION SOURCE DEST PROTO DEST PORT(S) DNAT net dmz:<server local IP address>[:<server port>] <protocol> <port> If you don't specify the <server port>, it is assumed to be the same as <port>. Be sure to add your rules after the line that reads SECTION NEW. You run a Web Server on DMZ Computer 2 and you want to forward incoming TCP port 80 to that system #ACTION SOURCE DEST PROTO DEST PORT(S) Web(DNAT) net dmz:10.10.11.2 Web(ACCEPT) loc dmz:10.10.11.2 Entry 1 forwards port 80 from the Internet. Entry 2 allows connections from the local network. Several important points to keep in mind: When you are connecting to your server from your local systems, you must use the server's internal IP address (10.10.11.2) or you must use DNAT from the loc zone as well (see below). #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT(S) PORT(S) DEST Web(DNAT) loc dmz:10.10.11.2 - - - external-ip-address where external-ip-address is the IP address of the firewall's external interface. 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 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your external IP).#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE # PORT(S) DNAT net dmz:10.10.11.2:80 tcp 5000 If you want to be able to access your server from the local network using your external address, then if you have a static external IP you can replace the loc->dmz rule above with:#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST DNAT loc dmz:10.10.11.2 tcp 80 - <external IP>If you have a dynamic IP then you must ensure that your external interface is up before starting Shorewall and you must take steps as follows (assume that your external interface is eth0): Include the following in /etc/shorewall/params: ETH0_IP=$(find_interface_address eth0) Make your loc->dmz rule: #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST DNAT loc dmz:10.10.11.2 tcp 80 - $ETH0_IP If you want to access your server from the DMZ using your external IP address, see FAQ 2a. At this point, add the DNAT and ACCEPT rules for your servers. 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.
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. 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 or in your DMZ. Red Hat has an RPM for a caching name server (which also requires the 'bind' RPM) and for Bering users, there is dnscache.lrp. If you take this approach, you configure your internal systems to use the caching name server 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 if you choose to run the name server on your firewall. 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 server; you do that by adding the rules in /etc/shorewall/rules. If you run the name server on the firewall: #ACTION SOURCE DEST PROTO DEST PORT(S) DNS(ACCEPT) loc $FW DNS(ACCEPT) dmz $FW Run name server on DMZ computer 1: #ACTION SOURCE DEST PROTO DEST PORT(S) DNS(ACCEPT) loc dmz:10.10.11.1 DNS(ACCEPT) $FW dmz:10.10.11.1 In the rules shown above, DNS(ACCEPT)is an example of a defined macro. Shorewall includes a number of defined macros and you can add your own. To see the list of macros included with your version of Shorewall, run the command ls /usr/share/shorewall/macro.*. You don't have to use defined macros when coding a rule in /etc/shorewall/rules. The first example above (name server on the firewall) could also have been coded as follows: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT loc $FW tcp 53 ACCEPT loc $FW udp 53 ACCEPT dmz $FW tcp 53 ACCEPT dmz $FW udp 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. This page can be of help if you don't know the protocol and port involved.
Other Connections The three-interface sample includes the following rule: #ACTION SOURCE DEST PROTO DEST PORT(S) DNS(ACCEPT) $FW net That rule allow DNS access from your firewall and may be removed if you commented out the line in /etc/shorewall/policy allowing all connections from the firewall to the Internet. The sample also includes: #ACTION SOURCE DEST PROTO DEST PORT(S) SSH(ACCEPT) loc $FW SSH(ACCEPT) loc dmz Those rules allow you to run an SSH server on your firewall and in each of your DMZ systems and to connect to those servers from your local systems. If you wish to enable other connections between your systems, the general format for using a defined macro is: #ACTION SOURCE DEST PROTO DEST PORT(S) <macro>(ACCEPT) <source zone> <destination zone> The general format when not using a defined macro is:#ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT <source zone> <destination zone> <protocol> <port> You want to run a publicly-available DNS server on your firewall system Using defined macros: #ACTION SOURCE DEST PROTO DEST PORT(S) DNS(ACCEPT) net $FW Not using defined macros: #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT net $FW tcp 53 ACCEPT net $FW udp 53 Those rules would of course be in addition to the rules listed above under "If you run the 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 DEST PORT(S) 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 DEST PORT(S) ACCEPT loc $FW udp 53 ACCEPT net $FW tcp 80 Entry 1 allows the DNS Cache to be used. Entry 2 allows the weblet to work. Now modify /etc/shorewall/rules to add or remove 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 can enable Shorewall startup by editing /etc/shorewall/shorewall.conf and setting 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. A running firewall may be restarted using the shorewall restart command. If you want to totally remove any trace of Shorewall from your Netfilter configuration, use shorewall clear. The three-interface sample assumes that you want to enable routing to/from eth1 (your local network) and eth2 (DMZ) when Shorewall is stopped. If these two interfaces don't connect to your local network and DMZ or if you want to enable a different set of hosts, modify /etc/shorewall/routestopped accordingly. If you are connected to your firewall from the Internet, do not issue a shorewall stop command unless you have added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. Also, I don't recommend using shorewall restart; 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 interface 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.
shorewall-docs-xml-4.5.21/Install.xml0000644000175000017500000013574312222401136017361 0ustar teastepteastep
Shorewall Installation and Upgrade Tom Eastep 2001- 2006 2009 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. This article applies to Shorewall 4.3 and later. If you are installing or upgrading to a version of Shorewall earlier than Shorewall 4.3.5 then please see the documentation for that release. Before attempting installation, I strongly urge you to read and print a copy of the Shorewall QuickStart Guide for the configuration that most closely matches your own. This article only tells you how to install the product on your system. The QuickStart Guides describe how to configure the product. Before upgrading, be sure to review the Upgrade Issues. Shorewall RPMs are signed. To avoid warnings such as the followingwarning: shorewall-3.2.1-1.noarch.rpm: V3 DSA signature: NOKEY, key ID 6c562ac4 download the Shorewall GPG key and run this command: rpm --import shorewall.gpg.key
Install using RPM To install Shorewall using the RPM: Be sure that you have the correct RPM package! The standard RPM package from shorewall.net and the mirrors is known to work with SUSE, Power PPC, Trustix and TurboLinux. There is also an RPM package provided by Simon Matter that is tailored for RedHat/Fedora and another package from Jack Coates that is customized for Mandriva. All of these are available from the download page. If you try to install the wrong package, it probably won't work. Install the RPMs rpm -ivh <shorewall rpm> Some users are in the habit of using the rpm -U command for installing packages as well as for updating them. If you use that command when installing the Shorewall RPM then you will have to manually enable Shorewall startup at boot time by running chkconfig, insserv or whatever utility you use to manipulate you init symbolic links. Shorewall is dependent on the iproute package. Unfortunately, some distributions call this package iproute2 which will cause the installation of Shorewall to fail with the diagnostic: error: failed dependencies:iproute is needed by shorewall-3.2.x-1 This problem should not occur if you are using the correct RPM package (see 1., above) but may be worked around by using the --nodeps option of rpm. rpm -ivh --nodeps <rpms> Example:rpm -ivh shorewall-4.3.5-0base.noarch.rpm
Install using tarball
Versions 4.5.2 and Later Shorewall 4.5.2 introduced a change in the philosopy used by the Shorewall installers. 4.5.2 introduced the concept of shorewallrc files. These files define the parameters to the install process. During the first installation using Shorewall-core 4.5.2 or later, a shorewallrc file named ${HOME}/.shorewallrc will be installed. That file will provide the default parameters for installing other Shorewall components of the same or later verion. Note that you must install Shorewall-core before installing any other Shorewall package. Each of the Shorewall packages contains a set of distribution-specific shorewallrc files: shorewallrc.apple (OS X) shorewallrc.archlinux shorewallrc.cygwin (Cygwin running on Windows) shorewallrc.debian (Debian and derivatives) shoreallrc.default (Generic Linux) shorewallrc.redhat (Fedora, RHEL and derivatives) shorewallrc.slackware shorewallrc.suse (SLES and OpenSuSE) When installing 4.5.2 or later for the first time, a special procedure must be followed: Select the shorewallrc file that is closest to your needs. Review the settings in the file. If you want to change something then you have two choices: Copy the file to shorewallrc and edit the copy to meet your needs; or If the system has Bash (/bin/bash) 4.0 or later installed, you can run ./configure (see below). If you are installing 4.5.2.1 or later and your system has Perl installed, you can use the Perl version (./configure.pl). ./install.sh If you don't need to change the file, then simply: ./install.sh shorewallrcfile-that-meets-your-needs Example: ./install shorewallrc.debian The shorewall-core install.sh script will store the shorewallrc file in ~/.shorewallrc where it will provide the defaults for future installations of all Shorewall products. Other packages/versions can be installed by simply typing ./install.sh
Settings in a shorewallrc file A shorewallrc file contains a number of lines of the form option=value. Because some of the installers are shared between Shorewall products, the files assume the definition of the symbol PRODUCT. $PRODUCT will contain the name of a Shorewall product (shorewall-core, shorewall, shorewall6, shorewall-lite, shorewall6-lite or shorewall-init). Valid values for option are: HOST Selects the shorewallrc file to use for default settings. Valid values are: apple OS X archlinux Archlinux cygwin Cygwin running under Windows debian Debian and derivatives (Ubuntu, Kbuntu, etc) default Generic Linux redhat Fedora, RHEL and derivatives (CentOS, Foobar, etc) slackware Slackware Linux suse SLES and OpenSuSe PREFIX Top-level directory under which most Shorewall components are installed. All standard shorewallrc files define this as \usr. SHAREDIR The directory where most Shorewall components are installed. In all of the standard shorewallrc file, this option has the value ${PREFIX}/share. LIBEXECDIR Directory where internal executables are stored. In the standard shorewallrc files, the default is either ${PREFIX}/share or ${PREFIX}/libexec PERLLIBDIR Directory where the Shorewall Perl modules are installed. Then will be installed in this directory under the sub-directory Shorewall. Default is distribution-specific. CONFDIR Directory where subsystem configuration data is stored. Default is /etc in all shorewallrc file. SBINDIR Directory where CLI programs will be installed. Default in all shorewallrc files is /sbin. MANDIR Directory under which manpages are to be installed. Default is distribution dependent. INITDIR Directory under which SysV init scripts are installed. Default is distribution dependent. INITSOURCE File in the package that is to be installed as the SysV init script for the product. INITFILE The name of the SysV init script when installed under $INITDIR. May be empty, in which case no SysV init script will be installed. This is usually the case on systems that run systemd and on systems like Cygwin or OS X where Shorewall can't act as a firewall. AUXINITSOURCE and AUXINITFILE Analogs of INITSOURCE and INITFILE for distributions, like Slackware, that have a master SysV init script and multiple subordinate scripts. SYSTEMD The directory under which the product's .service file is to be installed. Should only be specified on systems running systemd. SERVICEFILE Added in Shorewall 4.5.20. When SYSTEMD is specified, this variable names the file to be installed as the product's .service file. If not specified, $PRODUCT.service is assumed. SYSCONFDIR The directory where package SysV init configuration files are to be installed. /etc/default on Debian and derivatives and /etc/sysconfig otherwise SYSCONFFILE The file in the Shorewall package that should be installed as ${SYSCONFDIR}/$PRODUCT ANNOTATED Value is either empty or non-empty. Non-empty indicates that files in ${CONFDIR}/${PRODUCT} should be annotated with manpage documentation. SPARSE Value is either empty or non-empty. When non-empty, only ${PRODUCT}.conf will be installed in ${CONFDIR}/${PRODUCT} VARLIB Added in Shorewall 4.5.8. Directory where subsystem state data is to be stored. Default is /var/lib. VARDIR Shorewall 4.5.7 and earlier: Directory where subsystem state data is to be stored. Default is /var/lib. Shorewall 4.5.8 and later: Default is /var/lib/$PRODUCT. From Shorewall 4.5.2 through 4.5.7, there were two interpretations of VARDIR. In the shorewallrc file, it referred to the directory where all Shorewall product state would be stored (default /var/lib). But in the code and in shorewall-vardir(5), it referred to the directory where an individual products state would be stored (e.g., /var/lib/shorewall). In Shorewall 4.5.8, the variable VARLIB was added to shorewallrc. In that release, the shorewallrc files packaged with the Shorewall products were changed to include these two lines: VARLIB=/var/lib VARDIR defaults to '${VARLIB}/${PRODUCT}' if VARLIB is specified and VARDIR isn't. The consumers of shorewallrc were changed so that if there is no VARLIB setting, then VARLIB is set to $VARDIR and $VARDIR is set to ${VARLIB}/${PRODUCT}. This allows existing shorewallrc files to be used unchanged.
configure Script The configure script requires Bash 4.0 or later. Beginning with Shorewall 4.5.2.1, a Perl version (configure.pl) of the script is included for use by packagers that have to deal with systems with earlier versions of Bash. The configure.pl script works identically to the Bash version. The configure script creates a file named shorewallrc in the current working directory. This file is the default input file to the install.sh scripts. It is run as follows: ./configure[.pl] [ option=value ] ... The possible values for option are the same as those shone above in the shorewallrc file. They may be specified in either upper or lower case and may optionally be prefixed by '--'. To facilitate use with the rpm %configure script, the following options are supported: vendor Alias for host. sharedstatedir Shorewall 4.5.2 - 4.5.7 Alias for vardir. Shorewall 4.5.8 and later. Alias for varlib. datadir Alias for sharedir. Note that %configure may dsgenerate option/value pairs that are incompatible with the configure script. The current %configure macro is: %configure \ CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \ CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \ FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \ ./configure --host=%{_host} --build=%{_build} \\\ --target=%{_target_platform} \\\ --program-prefix=%{?_program_prefix} \\\ --prefix=%{_prefix} \\\ --exec-prefix=%{_exec_prefix} \\\ --bindir=%{_bindir} \\\ --sbindir=%{_sbindir} \\\ --sysconfdir=%{_sysconfdir} \\\ --datadir=%{_datadir} \\\ --includedir=%{_includedir} \\\ --libdir=%{_libdir} \\\ --libexecdir=%{_libexecdir} \\\ --localstatedir=%{_localstatedir} \\\ --sharedstatedir=%{_sharedstatedir} \\\ --mandir=%{_mandir} \\\ --infodir=%{_infodir} On Fedora 16, this expands to: CFLAGS="${CFLAGS:--O2 -g -march=i386 -mtune=i686}" ; export CFLAGS ; CXXFLAGS="${CXXFLAGS:--O2 -g -march=i386 -mtune=i686}" ; export CXXFLAGS ; FFLAGS="${FFLAGS:--O2 -g -march=i386 -mtune=i686}" ; export FFLAGS ; ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu \ --program-prefix= \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --sysconfdir=/etc \ --datadir=/usr/share \ --includedir=/usr/include \ --libdir=/usr/lib \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --sharedstatedir=/var/lib \ --mandir=/usr/share/man \ --infodir=/usr/share/info The value of --host does not map to any of the valid HOST values in shorewallrc. So to use %configure on a Fedora system, you want to invoke it as follows: %configure --vendor=redhat To reset the value of a setting in shorewallrc.$host, give it a null value. For example, if you are installing on a RHEL derivative that doesn't run systemd, use this command: ./configure --vendor=redhat --systemd=
Versions 4.5.1 and Earlier Beginning with Shorewall-4.5.0, the Shorewall packages depend on Shorewall-core. So the first step is to install that package: unpack the tarballs:tar -jxf shorewall-core-4.5.0.tar.bz2 cd to the shorewall directory (the version is encoded in the directory name as in shorewall-core-4.5.0). Type: ./install.sh To install Shorewall using the tarball and install script: unpack the tarballs:tar -jxf shorewall-4.5.0.tar.bz2 cd to the shorewall directory (the version is encoded in the directory name as in shorewall-4.3.5). Type: ./install.sh or if you are installing Shorewall or Shorewall6 version 4.4.8 or later, you may type: ./install.sh -s The -s option supresses installation of all files in /etc/shorewall except shorewall.conf. You can copy any other files you need from one of the Samples or from /usr/share/shorewall/configfiles/. If the install script was unable to configure Shorewall to be started automatically at boot, see these instructions. Beginning with shorewall 4.4.20.1, the installer also supports a (annotated) option. Beginning with that release, the standard configuration files (including samples) may be annotated with the contents of the associated manpage. The option enables that behavior. The default remains that the configuration files do not include documentation.
Executables in /usr and Perl Modules Distributions have different philosophies about the proper file hierarchy. Two issures are particularly contentious: Executable files in /usr/share/shorewall*. These include; getparams compiler.pl wait4ifup shorecap ifupdown Perl Modules in /usr/share/shorewall/Shorewall. To allow distributions to designate alternate locations for these files, the installers (install.sh) from 4.4.19 onward support the following environmental variables: LIBEXEC Determines where in /usr getparams, compiler.pl, wait4ifup, shorecap and ifupdown are installed. Shorewall and Shorewall6 must be installed with the same value of LIBEXEC. The listed executables are installed in /usr/${LIBEXEC}/shorewall*. The default value of LIBEXEC is 'share'. LIBEXEC is recognized by all installers and uninstallers. Beginning with Shorewall 4.4.20, you can specify an absolute path name for LIBEXEC, in which case the listed executables will be installed in ${LIBEXEC}/shorewall*. Beginning with Shorewall 4.5.1, you must specify an absolute pathname for LIBEXEC. PERLLIB Determines where in /usr the Shorewall Perl modules are installed. Shorewall and Shorewall6 must be installed with the same value of PERLLIB. The modules are installed in /usr/${PERLLIB}/Shorewall. The default value of PERLLIB is 'share/shorewall'. PERLLIB is only recognized by the Shorewall and Shorewall6 installers. Beginning with Shorewall 4.4.20, you can specify an absolute path name for PERLLIB, in which case the Shorewall Perl modules will be installed in ${PERLLIB}/Shorewall/. Beginning with Shorewall 4.5.1, you must specify an absolute pathname for PERLLIB. MANDIR Determines where the man pages are installed. Default is distribution-dependent as shown below.
Default Install Locations The default install locations are distribution dependent as shown in the following sections. These are the locations that are chosen by the install.sh scripts.
All Distributions COMPONENT LOCATION man pages /usr/share/man/ (may ve overridden using MANDIR) Shorewall Perl Modules /usr/share/shorewall/ (may be overridden using PERLLIB) Executable helper scripts (compiler.pl, getparams, wait4ifup) /usr/share/shorewall/ (may be overridden using LIBEXEC) ifupdown.sh (from Shorewall-init) /usr/share/shorewall-init/ (may be overridden using LIBEXEC)
Debian COMPONENT LOCATION CLI programs /sbin/product Distribution-specific configuration file /etc/default/product Init Scripts /etc/init.d/product ifupdown scripts from Shorewall-init /etc/network/if-up.d/shorewall, /etc/network/if-post-down.d/shorewall ppp ifupdown scripts from Shorewall-init /etc/ppp/ip-up.d/shorewall, /etc/ppp/ip-down.d/shorewall /etc/ppp/ipv6-up.d/shorewall /etc/ppp/ipv6-down.d/shorewall
Redhat and Derivatives COMPONENT LOCATION CLI programs /sbin/product Distribution-specific configuration file /etc/sysconfig/product Init Scripts /etc/rc.d/init.d/product ifupdown scripts from Shorewall-init /sbin/ifup-local, /sbin/ifdown-local ppp ifupdown scripts from Shorewall-init /etc/ppp/ip-up.local, /etc/ppp/ip-down.local
SuSE COMPONENT LOCATION CLI programs /sbin/product Distribution-specific configuration file /etc/sysconfig/product Init Scripts /etc/init.d/product ifupdown scripts from Shorewall-init /etc/sysconfig/network/if-up.d/shorewall, /etc/sysconfig/network/if-down.d/shorewall ppp ifupdown scripts from Shorewall-init /etc/ppp/ip-up.d/shorewall, /etc/ppp/ip-down.d/shorewall /etc/ppp/ipv6-up.d/shorewall /etc/ppp/ipv6-down.d/shorewall
Cygwin COMPONENT LOCATION CLI programs /bin/product Distribution-specific configuration file N/A Init Scripts N/A ifupdown scripts from Shorewall-init N/A ppp ifupdown scripts from Shorewall-init N/A
OS X COMPONENT LOCATION CLI programs /sbin/product Distribution-specific configuration file N/A Init Scripts N/A ifupdown scripts from Shorewall-init N/A ppp ifupdown scripts from Shorewall-init N/A
Install the .deb Once you have installed the .deb packages 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 Debian package. The easiest way to install Shorewall on Debian, is to use apt-get. First, to ensure that you are installing the latest version of Shorewall, please modify your /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: 700Then run:# apt-get update # apt-get install shorewall Once you have completed configuring Shorewall, you can enable startup at boot time by setting startup=1 in /etc/default/shorewall.
General Notes about Upgrading Shorewall Most problems associated with upgrades come from two causes: The user didn't read and follow the migration considerations in the release notes (these are also reproduced in the Shorewall Upgrade Issues). The user mis-handled the /etc/shorewall/shorewall.conf file during upgrade. Shorewall is designed to allow the default behavior of the product to evolve over time. To make this possible, the design assumes that you will not replace your current shorewall.conf file during upgrades. It is recommended that after you first install Shorewall that you modify /etc/shorewall/shorewall.conf so as to prevent your package manager from overwriting it during subsequent upgrades (since the addition of STARTUP_ENABLED, such modification is assured since you must manually change the setting of that option). If you feel absolutely compelled to have the latest options in your shorewall.conf then you must proceed carefully. You should determine which new options have been added and you must reset their value (e.g. OPTION=""); otherwise, you will get different behavior from what you expect.
Upgrade using RPM If you already have the Shorewall RPM installed and are upgrading to a new version: Be sure that you have the correct RPM package! The standard RPM package from shorewall.net and the mirrors is known to work with SUSE, Power PPC, Trustix and TurboLinux. There is also an RPM package provided by Simon Matter that is tailored for RedHat/Fedora and another package from Jack Coates that is customized for Mandriva. If you try to upgrade using the wrong package, it probably won't work. Simon Matter names his 'common' rpm 'shorewall' rather than 'shorewall-common'. If you are upgrading from a 2.x or 3.x version to a 4.x version or later, please see the upgrade issues for specific instructions. Upgrade the RPM rpm -Uvh <shorewall rpm file> Shorewall is dependent on the iproute package. Unfortunately, some distributions call this package iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic: error: failed dependencies:iproute is needed by shorewall-3.2.1-1 This may be worked around by using the --nodeps option of rpm. rpm -Uvh --nodeps <shorewall rpm> ... See if there are any incompatibilities between your configuration and the new Shorewall version and correct as necessary. shorewall check Restart the firewall. shorewall restart
Upgrade using tarball If you are upgrading from a 2.x or 3.x version to a 4.x version or later, please see the upgrade issues for specific instructions. If you are upgrading to version 4.5.0 or later, you must first install or upgrade the Shorewall-core package: unpack the tarballs:tar -jxf shorewall-core-4.5.0.tar.bz2 cd to the shorewall directory (the version is encoded in the directory name as in shorewall-core-4.5.0). Type: ./install.sh If you already have Shorewall installed and are upgrading to a new version using the tarball: unpack the tarball:tar -jxf shorewall-4.5.0.tar.bz2 cd to the shorewall-perl directory (the version is encoded in the directory name as in shorewall-4.5.0). Type: ./install.sh or if you are installing Shorewall or Shorewall6 version 4.4.8 or later, you may type: ./install.sh -s The -s option supresses installation of all files in /etc/shorewall except shorewall.conf. You can copy any other files you need from one of the Samples or from /usr/share/shorewall/configfiles/. See if there are any incompatibilities between your configuration and the new Shorewall version and correct as necessary. shorewall check Start the firewall by typing shorewall start If the install script was unable to configure Shorewall to be started automatically at boot, see these instructions.
Upgrading the .deb When the installer asks if you want to replace /etc/shorewall/shorewall.conf with the new version, we strongly advise you to say No. See above.
Configuring Shorewall You will need to edit some or all of the configuration files to match your setup. In most cases, the Shorewall QuickStart Guides contain all of the information you need.
Uninstall/Fallback See Fallback and Uninstall.
shorewall-docs-xml-4.5.21/ISO-3661.xml0000644000175000017500000004032312222401136016767 0ustar teastepteastep
ISO 3661 Country Codes recognized by Shorewall 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 Beginning with Shorewall 4.5.4, Shorewall allows matching packet SOURCE and/or DEST IP addresses by their corresponding country. That is done by specifying a comma-separated list of up to 15 ISO-3661 2-character Country Codes enclosed in square brackets ('[...]') and prefixed by a caret ('^'). When a single country code is given, the square brackets can be omitted. Example - Drop email from the Anonymous Proxy and Satellite Provider networks. /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST # PORT(S) DROP:info net:^[A1,A2] dmz tcp 25 Using this feature requires the GeoIP Match capability in your iptables and kernel. As of this writing, that capability requires installing xtables-addons 1.33 or later and creating a country-code database. The Shorewall compiler uses the geoip country-code database to determine the valid set of two-character alphanumeric country codes. The location of that database is currently hard-coded in xtables-addons as /usr/share/xt_geoip/. Within that directory are two sub-directories: LE -- contains the little-endian database BE -- contains the big-endian database To accomodate both big-endian and little-endian machines as well as any future ability to install the database at another location, Shorewall supports a GEOIPDIR option in shorewall.conf (5) and shorewall6.conf (5). The default value of that option is /usr/share/xt_geoip/LE. The country codes at the time of this writing are shown in the following two sections.
IPv4 A1 => "Anonymous Proxy" , A2 => "Satellite Provider" , AD => "Andorra" , AE => "United Arab Emirates" , AF => "Afghanistan" , AG => "Antigua and Barbuda" , AI => "Anguilla" , AL => "Albania" , AM => "Armenia" , AN => "Netherlands Antilles" , AO => "Angola" , AP => "Asia/Pacific Region" , AQ => "Antarctica" , AR => "Argentina" , AS => "American Samoa" , AT => "Austria" , AU => "Australia" , AW => "Aruba" , AX => "Aland Islands" , AZ => "Azerbaijan" , BA => "Bosnia and Herzegovina" , BB => "Barbados" , BD => "Bangladesh" , BE => "Belgium" , BF => "Burkina Faso" , BG => "Bulgaria" , BH => "Bahrain" , BI => "Burundi" , BJ => "Benin" , BM => "Bermuda" , BN => "Brunei Darussalam" , BO => "Bolivia" , BR => "Brazil" , BS => "Bahamas" , BT => "Bhutan" , BV => "Bouvet Island" , BW => "Botswana" , BY => "Belarus" , BZ => "Belize" , CA => "Canada" , CC => "Cocos (Keeling) Islands" , CD => "Congo, The Democratic Republic of the" , CF => "Central African Republic" , CG => "Congo" , CH => "Switzerland" , CI => "Cote D'Ivoire" , CK => "Cook Islands" , CL => "Chile" , CM => "Cameroon" , CN => "China" , CO => "Colombia" , CR => "Costa Rica" , CU => "Cuba" , CV => "Cape Verde" , CX => "Christmas Island" , CY => "Cyprus" , CZ => "Czech Republic" , DE => "Germany" , DJ => "Djibouti" , DK => "Denmark" , DM => "Dominica" , DO => "Dominican Republic" , DZ => "Algeria" , EC => "Ecuador" , EE => "Estonia" , EG => "Egypt" , EH => "Western Sahara" , ER => "Eritrea" , ES => "Spain" , ET => "Ethiopia" , EU => "Europe" , FI => "Finland" , FJ => "Fiji" , FK => "Falkland Islands (Malvinas)" , FM => "Micronesia, Federated States of" , FO => "Faroe Islands" , FR => "France" , GA => "Gabon" , GB => "United Kingdom" , GD => "Grenada" , GE => "Georgia" , GF => "French Guiana" , GG => "Guernsey" , GH => "Ghana" , GI => "Gibraltar" , GL => "Greenland" , GM => "Gambia" , GN => "Guinea" , GP => "Guadeloupe" , GQ => "Equatorial Guinea" , GR => "Greece" , GS => "South Georgia and the South Sandwich Islands" , GT => "Guatemala" , GU => "Guam" , GW => "Guinea-Bissau" , GY => "Guyana" , HK => "Hong Kong" , HN => "Honduras" , HR => "Croatia" , HT => "Haiti" , HU => "Hungary" , ID => "Indonesia" , IE => "Ireland" , IL => "Israel" , IM => "Isle of Man" , IN => "India" , IO => "British Indian Ocean Territory" , IQ => "Iraq" , IR => "Iran, Islamic Republic of" , IS => "Iceland" , IT => "Italy" , JE => "Jersey" , JM => "Jamaica" , JO => "Jordan" , JP => "Japan" , KE => "Kenya" , KG => "Kyrgyzstan" , KH => "Cambodia" , KI => "Kiribati" , KM => "Comoros" , KN => "Saint Kitts and Nevis" , KP => "Korea, Democratic People's Republic of" , KR => "Korea, Republic of" , KW => "Kuwait" , KY => "Cayman Islands" , KZ => "Kazakhstan" , LA => "Lao People's Democratic Republic" , LB => "Lebanon" , LC => "Saint Lucia" , LI => "Liechtenstein" , LK => "Sri Lanka" , LR => "Liberia" , LS => "Lesotho" , LT => "Lithuania" , LU => "Luxembourg" , LV => "Latvia" , LY => "Libyan Arab Jamahiriya" , MA => "Morocco" , MC => "Monaco" , MD => "Moldova, Republic of" , ME => "Montenegro" , MG => "Madagascar" , MH => "Marshall Islands" , MK => "Macedonia" , ML => "Mali" , MM => "Myanmar" , MN => "Mongolia" , MO => "Macau" , MP => "Northern Mariana Islands" , MQ => "Martinique" , MR => "Mauritania" , MS => "Montserrat" , MT => "Malta" , MU => "Mauritius" , MV => "Maldives" , MW => "Malawi" , MX => "Mexico" , MY => "Malaysia" , MZ => "Mozambique" , NA => "Namibia" , NC => "New Caledonia" , NE => "Niger" , NF => "Norfolk Island" , NG => "Nigeria" , NI => "Nicaragua" , NL => "Netherlands" , NO => "Norway" , NP => "Nepal" , NR => "Nauru" , NU => "Niue" , NZ => "New Zealand" , OM => "Oman" , PA => "Panama" , PE => "Peru" , PF => "French Polynesia" , PG => "Papua New Guinea" , PH => "Philippines" , PK => "Pakistan" , PL => "Poland" , PM => "Saint Pierre and Miquelon" , PR => "Puerto Rico" , PS => "Palestinian Territory, Occupied" , PT => "Portugal" , PW => "Palau" , PY => "Paraguay" , QA => "Qatar" , RE => "Reunion" , RO => "Romania" , RS => "Serbia" , RU => "Russian Federation" , RW => "Rwanda" , SA => "Saudi Arabia" , SB => "Solomon Islands" , SC => "Seychelles" , SD => "Sudan" , SE => "Sweden" , SG => "Singapore" , SH => "Saint Helena" , SI => "Slovenia" , SJ => "Svalbard and Jan Mayen" , SK => "Slovakia" , SL => "Sierra Leone" , SM => "San Marino" , SN => "Senegal" , SO => "Somalia" , SR => "Suriname" , ST => "Sao Tome and Principe" , SV => "El Salvador" , SY => "Syrian Arab Republic" , SZ => "Swaziland" , TC => "Turks and Caicos Islands" , TD => "Chad" , TF => "French Southern Territories" , TG => "Togo" , TH => "Thailand" , TJ => "Tajikistan" , TK => "Tokelau" , TL => "Timor-Leste" , TM => "Turkmenistan" , TN => "Tunisia" , TO => "Tonga" , TR => "Turkey" , TT => "Trinidad and Tobago" , TV => "Tuvalu" , TW => "Taiwan" , TZ => "Tanzania, United Republic of" , UA => "Ukraine" , UG => "Uganda" , UM => "United States Minor Outlying Islands" , US => "United States" , UY => "Uruguay" , UZ => "Uzbekistan" , VA => "Holy See (Vatican City State)" , VC => "Saint Vincent and the Grenadines" , VE => "Venezuela" , VG => "Virgin Islands, British" , VI => "Virgin Islands, U.S." , VN => "Vietnam" , VU => "Vanuatu" , WF => "Wallis and Futuna" , WS => "Samoa" , YE => "Yemen" , YT => "Mayotte" , ZA => "South Africa" , ZM => "Zambia" , ZW => "Zimbabwe" ,
IPv6 AD => "Andorra" , AE => "United Arab Emirates" , AF => "Afghanistan" , AL => "Albania" , AM => "Armenia" , AO => "Angola" , AP => "Asia/Pacific Region" , AR => "Argentina" , AS => "American Samoa" , AT => "Austria" , AU => "Australia" , AW => "Aruba" , AZ => "Azerbaijan" , BA => "Bosnia and Herzegovina" , BD => "Bangladesh" , BE => "Belgium" , BF => "Burkina Faso" , BG => "Bulgaria" , BH => "Bahrain" , BI => "Burundi" , BJ => "Benin" , BM => "Bermuda" , BN => "Brunei Darussalam" , BO => "Bolivia" , BR => "Brazil" , BS => "Bahamas" , BT => "Bhutan" , BW => "Botswana" , BY => "Belarus" , BZ => "Belize" , CA => "Canada" , CD => "Congo, The Democratic Republic of the" , CH => "Switzerland" , CI => "Cote D'Ivoire" , CK => "Cook Islands" , CL => "Chile" , CM => "Cameroon" , CN => "China" , CO => "Colombia" , CR => "Costa Rica" , CU => "Cuba" , CW => "" , CY => "Cyprus" , CZ => "Czech Republic" , DE => "Germany" , DJ => "Djibouti" , DK => "Denmark" , DO => "Dominican Republic" , DZ => "Algeria" , EC => "Ecuador" , EE => "Estonia" , EG => "Egypt" , ES => "Spain" , EU => "Europe" , FI => "Finland" , FJ => "Fiji" , FM => "Micronesia, Federated States of" , FO => "Faroe Islands" , FR => "France" , GB => "United Kingdom" , GD => "Grenada" , GE => "Georgia" , GG => "Guernsey" , GH => "Ghana" , GI => "Gibraltar" , GL => "Greenland" , GM => "Gambia" , GP => "Guadeloupe" , GR => "Greece" , GT => "Guatemala" , GU => "Guam" , GY => "Guyana" , HK => "Hong Kong" , HN => "Honduras" , HR => "Croatia" , HT => "Haiti" , HU => "Hungary" , ID => "Indonesia" , IE => "Ireland" , IL => "Israel" , IM => "Isle of Man" , IN => "India" , IQ => "Iraq" , IR => "Iran, Islamic Republic of" , IS => "Iceland" , IT => "Italy" , JE => "Jersey" , JM => "Jamaica" , JO => "Jordan" , JP => "Japan" , KE => "Kenya" , KG => "Kyrgyzstan" , KH => "Cambodia" , KN => "Saint Kitts and Nevis" , KR => "Korea, Republic of" , KW => "Kuwait" , KY => "Cayman Islands" , KZ => "Kazakhstan" , LA => "Lao People's Democratic Republic" , LB => "Lebanon" , LI => "Liechtenstein" , LK => "Sri Lanka" , LS => "Lesotho" , LT => "Lithuania" , LU => "Luxembourg" , LV => "Latvia" , LY => "Libyan Arab Jamahiriya" , MA => "Morocco" , MC => "Monaco" , MD => "Moldova, Republic of" , ME => "Montenegro" , MG => "Madagascar" , MH => "Marshall Islands" , MK => "Macedonia" , ML => "Mali" , MM => "Myanmar" , MN => "Mongolia" , MO => "Macau" , MT => "Malta" , MU => "Mauritius" , MV => "Maldives" , MW => "Malawi" , MX => "Mexico" , MY => "Malaysia" , MZ => "Mozambique" , NA => "Namibia" , NC => "New Caledonia" , NF => "Norfolk Island" , NG => "Nigeria" , NI => "Nicaragua" , NL => "Netherlands" , NO => "Norway" , NP => "Nepal" , NR => "Nauru" , NU => "Niue" , NZ => "New Zealand" , OM => "Oman" , PA => "Panama" , PE => "Peru" , PF => "French Polynesia" , PG => "Papua New Guinea" , PH => "Philippines" , PK => "Pakistan" , PL => "Poland" , PR => "Puerto Rico" , PS => "Palestinian Territory" , PT => "Portugal" , PW => "Palau" , PY => "Paraguay" , QA => "Qatar" , RO => "Romania" , RS => "Serbia" , RU => "Russian Federation" , RW => "Rwanda" , SA => "Saudi Arabia" , SB => "Solomon Islands" , SC => "Seychelles" , SD => "Sudan" , SE => "Sweden" , SG => "Singapore" , SI => "Slovenia" , SK => "Slovakia" , SL => "Sierra Leone" , SM => "San Marino" , SN => "Senegal" , SO => "Somalia" , ST => "Sao Tome and Principe" , SV => "El Salvador" , SY => "Syrian Arab Republic" , SZ => "Swaziland" , TH => "Thailand" , TK => "Tokelau" , TN => "Tunisia" , TO => "Tonga" , TR => "Turkey" , TT => "Trinidad and Tobago" , TV => "Tuvalu" , TW => "Taiwan" , TZ => "Tanzania, United Republic of" , UA => "Ukraine" , UG => "Uganda" , US => "United States" , UY => "Uruguay" , UZ => "Uzbekistan" , VA => "Holy See (Vatican City State)" , VE => "Venezuela" , VI => "Virgin Islands, U.S." , VN => "Vietnam" , VU => "Vanuatu" , WS => "Samoa" , YE => "Yemen" , ZA => "South Africa" , ZM => "Zambia" , ZW => "Zimbabwe" ,
shorewall-docs-xml-4.5.21/NewRelease.xml0000644000175000017500000000631312222401136017773 0ustar teastepteastep
Shorewall Release Model 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.
Identification Shorewall releases are identified by three numbers separated by periods (e.g., 4.4.16). The first two digits (e.g., 4.4) specify the major release number. The third number (e.g., 16) is the minor release number.
Release Schedule Traditionally, major releases have occurred roughly every two years, but as Shorewall has matured, new enhancements are routinely released in minor releases. Minor releases occur every 4 to 6 weeks. If a defect is discovered in a minor release for which there is no easy workaround or which can affect a large number of users, a bug-fix or point release is made. New minor and point releases are announced on the Shorewall Announcements mailing list and on the Shorewall Users mailing list. Current release information is also available on the Shorewall Home Page.
Beta Releases and Release Candidates Beta releases have their three-number identifaction follow by "-BetaN" (e.g., 4.4.17-Beta3). Beta releases are made approximately weekly and are announced on the Shorewall Development mailing list and on the Shorewall Users mailing list. At the point where the new features in a release are frozen, the Beta releases give way to release candidates. These have the three-number identification followed by "-RCN" (e.g., 4.4.17-RC1). They are announced in the same way as the betas.
shorewall-docs-xml-4.5.21/IPP2P.xml0000644000175000017500000002140312222401136016570 0ustar teastepteastep
Shorewall and ipp2p Tom Eastep 2004 2005 2006 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.
Introduction Shorewall includes support for the ipp2p match facility. This is a departure from my usual policy in that the ipp2p match facility is included in xtables-addons and is unlikely to ever be included in the kernel.org source tree. Questions about how to install xtables-addons or how to build your kernel and/or iptables should not be posted on the Shorewall mailing lists but should rather be referred to the Netfilter Mailing List.
Scope In the following files, the "PROTO" or "PROTOCOL" column may contain "ipp2p": /etc/shorewall/tcrules /etc/shorewall/accounting /etc/shorewall/rules (Not Recommend. But if you insist, then you should place the rules in the ESTABLISHED section of that file). When the PROTO or PROTOCOL column contains "ipp2p" then the DEST PORT(S) or PORT(S) column may contain a recognized ipp2p option (Shorewall-perl 4.2.5 and later accepts a comma-separated list of options); for a list of the options and their meaning, at a root prompt type: iptables -m ipp2p --help You must not include the leading "--" on the option(s); Shorewall will supply those characters for you. If you do not include an option then Shorewall will assume "edk,kazaa,gnu,dc". If 'ipp2p' is specified, Shorewall will substitute "edk,kazaa,gnu,dc".
Example: Example 2 in the ipp2p documentation recommends the following iptables rules: 01# iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark 02# iptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT 03# iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ipp2p -j MARK --set-mark 1 04# iptables -t mangle -A PREROUTING -p tcp -m mark --mark 1 -j CONNMARK --save-mark 05# iptables -t mangle -A POSTROUTING -o eth0 -m mark --mark 1 -j CLASSIFY --set-class 1:12 06# iptables -t mangle -A POSTROUTING -o eth1 -m mark --mark 1 -j CLASSIFY --set-class 2:12 Let's examine the above rules more carefully. The individual packets of a P2P data stream do not all carry tell-tale signs that are identifiable as being a particular P2P application. So simply asking the ipp2p match code to mark each individual packet isn't enough because only those packets that carry these tell-tale signs will be marked. Fortunately, Netfilter provides a different type of mark -- the Connection Mark which is associated with the entry in the conntrack table rather that with the individual packet. You can see connection mark values with the shorewall show connections command: gateway:/etc/test# shorewall show connections Shorewall-2.5.6 Connections at gateway - Tue Oct 4 15:45:11 PDT 2005 tcp 6 269712 ESTABLISHED src=192.168.3.8 dst=206.124.146.177 sport=50584 dport=993 packets=4899 bytes=302282 src=206.124.146.177 dst=192.168.3.8 sport=993 dport=50584 packets=7760 bytes=10032928 [ASSURED] mark=0 use=1 ... Connection marks are persistent -- that is, once a connection mark is set it retains its value until the connection is terminated. Netfilter provides features to: Mark individual packets with a numeric value. Save the current packet mark value in the connection mark. Restore the value in the connection mark to the current packet. The strategy employed in the above rules is to mark the connection of each P2P session with a mark value of 1. That way, each packet that is part of the session can be marked using the 'Restore' function and can be classified accordingly. Rule 01# restores the connection mark into the current packet. Rule 02# tests that restored mark and if it is not equal to zero, the packet is ACCEPTed (no further processing). Rule 03# asks the ipp2p match module to examine the packet and if it is identifiable as part of a P2P session, mark the packet with value 1. Rule 04# saves the current packet mark in the conntrack table if the current mark value is 1 (in other words, if it was marked by rule 03#). Rule 05# classifies the packet to traffic shaping class 1:12 if it is going out of eth0 and has mark value 1. Rule 06# classifies the packet to traffic shaping class 2:12 if it is going out of eth1 and has mark value 1. These are implemented in the /etc/shorewall/tcrules file as follows: #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST # PORT(S) RESTORE:P - - tcp CONTINUE:P - - tcp - - - !0 1:P - - ipp2p ipp2p SAVE:P - - tcp - - - 1 1:12 - eth0 - - - - 1 2:12 - eth1 - - - - 1 These rules do exactly the same thing as their counterparts described above. One change that I recommend --do your marking in the FORWARD chain rather than in the PREROUTING chain: #MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST # PORT(S) RESTORE:F - - tcp CONTINUE:F - - tcp - - - !0 1:F - - ipp2p ipp2p SAVE:F - - tcp - - - 1 1:12 - eth0 - - - - 1 2:12 - eth1 - - - - 1 It will work the same and will work with a Multi-ISP setup.
shorewall-docs-xml-4.5.21/shorewall_setup_guide.xml0000644000175000017500000030610312222401136022336 0ustar teastepteastep
Shorewall Setup Guide 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.
Introduction This guide is intended for users who are setting up Shorewall in an environment where a set of public IP addresses must be managed or who want to know more about Shorewall than is contained in the single-address guides. Because the range of possible applications is so broad, the Guide will give you general guidelines and will point you to other resources as necessary. Shorewall requires that the iproute/iproute2 package be 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. Points at which configuration changes are recommended are flagged with . 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 with Shorewall. 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
Shorewall Concepts The configuration files for Shorewall are contained in the directory /etc/shorewall -- for most setups, you will only need to deal with a few of these as described in this guide. Skeleton files are created during the Shorewall Installation Process. Note to Debian Users If you install using the .deb, you will find that your /etc/shorewall directory is 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. Note that you must copy /usr/share/doc/shorewall-common/default-config/shorewall.conf and /usr/share/doc/shorewall-common/default-config/modules to /etc/shorewall even if you do not modify those files. As each file is introduced, I suggest that you look through the actual file on your system -- each file contains detailed configuration instructions. Shorewall views the network where it is running as being composed of a set of zones. A zone is one or more hosts, which can be defined as individual hosts or networks in /etc/shorewall/hosts, or as an entire interface in /etc/shorewall/interfaces. In this guide, we will use the following zones: fw The firewall system itself. net The public Internet. loc A private local network using private IP addresses. dmz A Demilitarized Zone holding publicly-accessible servers. Zones are defined in the file /etc/shorewall/zones. The /etc/shorewall/zones file included in the release is empty. You can create the standard set of zones described above by copying and pasting the following into the file: #ZONE TYPE OPTIONS fw firewall net ipv4 loc ipv4 dmz ipv4 Note that Shorewall recognizes the firewall system as its own zone - The above example follows the usual convention of naming the Firewall zone fw. The name specified for the firewall zone (fw in the above example) is stored in the shell variable $FW when the /etc/shorewall/zones file is processed. With the exception of the name assigned to the firewall zone, Shorewall attaches absolutely no meaning to zone names. Zones are entirely what YOU make of them. That means that you should not expect Shorewall to do something special because this is the Internet zone or because that is the DMZ. Edit the /etc/shorewall/zones file and make any changes necessary. 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. Shorewall is built on top of the Netfilter kernel facility. Netfilter implements a connection tracking function that allows what is often referred to as stateful inspection of packets. This stateful property allows firewall rules to be defined in terms of connections rather than in terms of packets. With Shorewall, you: Identify the source (client) zone. Identify destination (server) zone. If the POLICY from the client's zone to the server's zone is what you want for this client/server pair, you need do nothing further. If the POLICY is not what you want, then you must add a rule. That rule is expressed in terms of the client's zone and the server's zone. Just because connections of a particular type are allowed from zone A to the firewall and are also allowed from the firewall to zone B DOES NOT mean that these connections are allowed from zone A to zone B (in other words, policies and rules involving the firewall zone are not transitive). It rather means that you can have a proxy running on the firewall that accepts a connection from zone A and then establishes its own separate connection from the firewall to zone B. 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 after the request is passed to the appropriate default action (if any). Prior to Shorewall 2.2.0, the default /etc/shorewall/policy file had the following policies: #SOURCE ZONE DESTINATION ZONE POLICY LOG LIMIT:BURST # LEVEL loc net ACCEPT net all DROP info all all REJECT info The currently released policy file is empty. You can copy and paste the above entries to create a starting point from which to customize your policies. The above policies 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 and log a message at the info level (here is a description of log levels). reject all other connection requests and log a message at the info level. When a request is rejected, the firewall will return an RST (if the protocol is TCP) or an ICMP port-unreachable packet for other protocols. At this point, edit your /etc/shorewall/policy and make any changes that you wish.
Network Interfaces For the remainder of this guide, we'll refer to the following diagram. While it may not look like your own network, it can be used to illustrate the important aspects of Shorewall configuration. In this diagram: The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is used to isolate your Internet-accessible servers from your local systems so that if one of those servers is compromised, you still have the firewall between the compromised system and your local systems. The Local Zone consists of systems Local 1, Local 2 and Local 3. All systems from the ISP outward comprise the Internet Zone. The simplest way to define zones is to associate the zone name (previously defined in /etc/shorewall/zones) with a network interface. This is done in the /etc/shorewall/interfaces file. The firewall illustrated above has three 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 using ISDN, you external interface will be ippp0. If your external interface is ppp0 or ippp0 then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf. Your Local Interface will be an Ethernet adapter (eth0, eth1 or eth2) and will be connected to a hub or switch. Your local computers will be connected to the same switch (note: If you have only a single local system, you can connect the firewall directly to the computer using a cross-over cable). Your DMZ Interface will also be an Ethernet adapter (eth0, eth1 or eth2) and will be connected to a hub or switch. Your DMZ computers will be connected to the same switch (note: If you have only a single DMZ 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. For the remainder of this Guide, we will assume that: The External Interface is eth0. The Local Interface eth1. The DMZ Interface eth2. The Shorewall default configuration does not define the contents of any zone. To define the above configuration using the /etc/shorewall/interfaces file, that file would might contain: #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect loc eth1 detect dmz eth2 detect Note that the $FW zone has no entry in the /etc/shorewall/interfaces file. Edit the /etc/shorewall/interfaces file and define the network interfaces on your firewall and associate each interface with a zone. If you have a zone that is interfaced through more than one interface, simply include one entry for each interface and repeat the zone name as many times as necessary. Multiple Interfaces to a Zone #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect loc eth1 detect loc eth2 detect You may define more complicated zones using the /etc/shorewall/hosts file but in most cases, that isn't necessary. See Shorewall_and_Aliased_Interfaces.html and Multiple_Zones.html for examples.
Addressing, Subnets and Routing Normally, your ISP will assign you a set of Public IP addresses. You will configure your firewall's external interface to use one of those addresses permanently and you will then have to decide how you are going to use the rest of your addresses. Before we tackle that question though, some background is in order. If you are thoroughly familiar with IP addressing and routing, you may go to the next section. The following discussion barely scratches the surface of addressing and routing. If you are interested in learning more about this subject, I highly recommend IP Fundamentals: What Everyone Needs to Know about Addressing & Routing, Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
IP Addresses IP version 4 (IPv4) addresses are 32-bit numbers. The notation w.x.y.z refers to an address where the high-order byte has value w, the next byte has value x, etc. If we take the address 192.0.2.14 and express it in hexadecimal, we get: C0.00.02.0Eor looking at it as a 32-bit integer C000020E
Subnets You will still hear the terms Class A network, Class B network and Class C network. In the early days of IP, networks only came in three sizes (there were also Class D networks but they were used differently): Class A - netmask 255.0.0.0, size = 2 ** 24 Class B - netmask 255.255.0.0, size = 2 ** 16 Class C - netmask 255.255.255.0, size = 256 The class of a network was uniquely determined by the value of the high order byte of its address so you could look at an IP address and immediately determine the associated netmask. The netmask is a number that when logically ANDed with an address isolates the network number; the remainder of the address is the host number. For example, in the Class C address 192.0.2.14, the network number is hex C00002 and the host number is hex 0E. As the Internet grew, it became clear that such a gross partitioning of the 32-bit address space was going to be very limiting (early on, large corporations and universities were assigned their own class A network!). After some false starts, the current technique of subnetting these networks into smaller subnetworks evolved; that technique is referred to as Classless InterDomain Routing (CIDR). Today, any system that you are likely to work with will understand CIDR and Class-based networking is largely a thing of the past. A subnetwork (often referred to as a subnet) is a contiguous set of IP addresses such that: The number of addresses in the set is a power of 2; and The first address in the set is a multiple of the set size. The first address in the subnet is reserved and is referred to as the subnet address. The last address in the subnet is reserved as the subnet's broadcast address. As you can see by this definition, in each subnet of size n there are (n - 2) usable addresses (addresses that can be assigned to hosts). The first and last address in the subnet are used for the subnet address and subnet broadcast address respectively. Consequently, small subnetworks are more wasteful of IP addresses than are large ones. Since n is a power of two, we can easily calculate the Base-2 Logarithm (log2) of n. For the more common subnet sizes, the size and its base-2 logarithm are given in the following table: Base-2 Logarithms n log2 n (32 - log2 n) 8 3 29 16 4 28 32 5 27 64 6 26 128 7 25 256 8 24 512 9 23 1024 10 22 2048 11 21 4096 12 20 8192 13 19 16384 14 18 32768 15 17 65536 16 16
You will notice that the above table also contains a column for (32 - log2 n). That number is the Variable Length Subnet Mask (VLSM) for a network of size n. From the above table, we can derive the following one which is a little easier to use. VLSM Subnet Size VLSM Subnet Mask 8 /29 255.255.255.248 16 /28 255.255.255.240 32 /27 255.255.255.224 64 /26 255.255.255.192 128 /25 255.255.255.128 256 /24 255.255.255.0 512 /23 255.255.254.0 1024 /22 255.255.252.0 2048 /21 255.255.248.0 4096 /20 255.255.240.0 8192 /19 255.255.224.0 16384 /18 255.255.192.0 32768 /17 255.255.128.0 65536 /16 255.255.0.0 2 ** 24 /8 255.0.0.0
Notice that the VLSM is written with a slash (/) -- you will often hear a subnet of size 64 referred to as a slash 26 subnet and one of size 8 referred to as a slash 29. The subnet's mask (also referred to as its netmask) is simply a 32-bit number with the first VLSM bits set to one and the remaining bits set to zero. For example, for a subnet of size 64, the subnet mask has 26 leading one bits: 11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 = 255.255.255.192The subnet mask has the property that if you logically AND the subnet mask with an address in the subnet, the result is the subnet address. Just as important, if you logically AND the subnet mask with an address outside the subnet, the result is NOT the subnet address. As we will see below, this property of subnet masks is very useful in routing. For a subnetwork whose address is a.b.c.d and whose Variable Length Subnet Mask is /v, we denote the subnetwork as a.b.c.d/v using CIDR Notation. Example: Subnet Subnet: 10.10.10.0 - 10.10.10.127 Subnet Size: 128 Subnet Address: 10.10.10.0 Broadcast Address: 10.10.10.127 CIDR Notation: 10.10.10.0/25
There are two degenerate subnets that need mentioning; namely, the subnet with one member and the subnet with 2 ** 32 members. /32 and /0 Subnet Size VLSM Length Subnet Mask CIDR Notation 1 32 255.255.255.255 a.b.c.d/32 32 0 0.0.0.0 0.0.0.0/0
So any address a.b.c.d may also be written a.b.c.d/32 and the set of all possible IP addresses is written 0.0.0.0/0. A Shorewall user has contributed a useful graphical summary of the above information. Later in this guide, you will see the notation a.b.c.d/v used to describe the ip configuration of a network interface (the ip utility also uses this syntax). This simply means that the interface is configured with ip address a.b.c.d and with the netmask that corresponds to VLSM /v. 192.0.2.65/29 The interface is configured with IP address 192.0.2.65 and netmask 255.255.255.248. /sbin/shorewall supports an ipcalc command that automatically calculates information about a [sub]network. Using the <command>ipcalc </command>command shorewall ipcalc 10.10.10.0/25 CIDR=10.10.10.0/25 NETMASK=255.255.255.128 NETWORK=10.10.10.0 BROADCAST=10.10.10.127 Using the <command>ipcalc</command> command shorewall ipcalc 10.10.10.0 255.255.255.128 CIDR=10.10.10.0/25 NETMASK=255.255.255.128 NETWORK=10.10.10.0 BROADCAST=10.10.10.127
Routing One of the purposes of subnetting is that it forms the basis for routing. Here's the routing table on my firewall (compressed for PDF): [root@gateway root]# netstat -nr Kernel IP routing table Destination Gateway Genmask Flgs MSS Win irtt Iface 192.168.9.1 0.0.0.0 255.255.255.255 UH 40 0 0 texas 206.124.146.177 0.0.0.0 255.255.255.255 UH 40 0 0 eth1 206.124.146.180 0.0.0.0 255.255.255.255 UH 40 0 0 eth3 192.168.3.0 0.0.0.0 255.255.255.0 U 40 0 0 eth3 192.168.2.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2 206.124.146.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 192.168.9.0 192.0.2.223 255.255.255.0 UG 40 0 0 texas 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo 0.0.0.0 206.124.146.254 0.0.0.0 UG 40 0 0 eth0 [root@gateway root]# The device texas is a GRE tunnel to a peer site in the Dallas, Texas area. The first three routes are host routes since they indicate how to get to a single host. In the netstat output this can be seen by the Genmask (Subnet Mask) of 255.255.255.255 and the H in the Flags column. The remainder are net routes since they tell the kernel how to route packets to a subnetwork. The last route is the default route and the gateway mentioned in that route is called the default gateway. When the kernel is trying to send a packet to IP address A, it starts at the top of the routing table and: A is logically ANDed with the Genmask value in the table entry. The result is compared with the Destination value in the table entry. If the result and the Destination value are the same, then: If the Gateway column is non-zero, the packet is sent to the gateway over the interface named in the Iface column. Otherwise, the packet is sent directly to A over the interface named in the iface column. Otherwise, the above steps are repeated on the next entry in the table. Since the default route matches any IP address (A LAND 0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing table entries are sent to the default gateway which is usually a router at your ISP. Lets take an example. Suppose that we want to route a packet to 192.168.1.5. That address clearly doesn't match any of the host routes in the table but if we logically and that address with 255.255.255.0, the result is 192.168.1.0 which matches this routing table entry: 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2 So to route a packet to 192.168.1.5, the packet is sent directly over eth2. One more thing needs to be emphasized -- all outgoing packet are sent using the routing table and reply packets are not a special case. There seems to be a common misconception whereby people think that request packets are like salmon and contain a genetic code that is magically transferred to reply packets so that the replies follow the reverse route taken by the request. That isn't the case; the replies may take a totally different route back to the client than was taken by the requests -- they are totally independent.
Address Resolution Protocol (ARP) When sending packets over Ethernet, IP addresses aren't used. Rather Ethernet addressing is based on Media Access Control (MAC) addresses. Each Ethernet device has its own unique MAC address which is burned into a PROM on the device during manufacture. You can obtain the MAC of an Ethernet device using the ip utility: [root@gateway root]# ip addr show 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 inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0 [root@gateway root]# As you can see from the above output, the MAC is 6 bytes (48 bits) wide. A card's MAC is usually also printed on a label attached to the card itself. Because IP uses IP addresses and Ethernet uses MAC addresses, a mechanism is required to translate an IP address into a MAC address; that is the purpose of the Address Resolution Protocol (ARP). Here is ARP in action: [root@gateway root]# tcpdump -nei eth2 arp tcpdump: listening on eth2 09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254 09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0 2 packets received by filter 0 packets dropped by kernel [root@gateway root]# In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants to know the MAC of the device with IP address 192.168.1.19. The system having that IP address is responding that the MAC address of the device with IP address 192.168.1.19 is 0:6:25:aa:8a:f0. In order to avoid having to exchange ARP information each time that an IP packet is to be sent, systems maintain an ARP cache of IP<->MAC correspondences. You can see the ARP cache on your system (including your Windows system) using the arp command: [root@gateway root]# arp -na ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1 ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2 ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2 ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0 ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2 The leading question marks are a result of my having specified the n option (Windows arp doesn't allow that option) which causes the arp program to forgo IP->DNS name translation. Had I not given that option, the question marks would have been replaced with the FQDN corresponding to each IP address. Notice that the last entry in the table records the information we saw using tcpdump above.
RFC 1918 IP addresses are allocated by the Internet Assigned Number Authority (IANA) who delegates allocations on a geographic basis to Regional Internet Registries (RIRs). For example, allocation for the Americas and for sub-Sahara Africa is delegated to the American Registry for Internet Numbers (ARIN). These RIRs may in turn delegate to national registries. Most of us don't deal with these registrars but rather get our IP addresses from our ISP. It's a fact of life that most of us can't afford as many Public IP addresses as we have devices to assign them to so we end up making use of Private IP addresses. RFC 1918 reserves several 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.255 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. This is understandable given that anyone can select any of these addresses for their private use but the term non-routable is somewhat unfortunate because it leads people to the erroneous conclusion that traffic destined for one of these addresses can't be sent through a router. This is definitely not true; private routers (including your Shorewall-based firewall) can forward RFC 1918 addressed traffic just fine. When selecting addresses from these ranges, there's a couple of things to keep in mind: As the IPv4 address space becomes depleted, more and more organizations (including ISPs) are beginning to use RFC 1918 addresses in their infrastructure. You don't want to use addresses that are being used by your ISP or by another organization with whom you want to establish a VPN relationship. So it's a good idea to check with your ISP to see if they are using (or are planning to use) private addresses before you decide the addresses that you are going to use. In this document, external real IP addresses are of the form 192.0.2.x. 192.0.2.0/24 is reserved by RFC 3330 for use as public IP addresses in printed examples and test networks. These "real" addresses are not to be confused with addresses in 192.168.0.0/16; as described above, those addresses are reserved by RFC 1918 for private use.
Setting Up Your Network The choice of how to set up your network depends primarily on how many Public IP addresses you have vs. how many addressable entities you have in your network. Regardless of how many addresses you have, your ISP will handle that set of addresses in one of two ways: Routed - Traffic to any of your addresses will be routed through a single gateway address. This will generally only be done if your ISP has assigned you a complete subnet (/29 or larger). In this case, you will assign the gateway address as the IP address of your firewall/router's external interface. Non-routed - Your ISP will send traffic to each of your addresses directly. In the subsections that follow, we'll look at each of these separately. Before we begin, there is one thing for you to check: If you are using the Debian package, please check your shorewall.conf file to ensure that the following are set correctly; if they are not, change them appropriately: IP_FORWARDING=On
Routed Let's assume that your ISP has assigned you the subnet 192.0.2.64/28 routed through 192.0.2.65. That means that you have IP addresses 192.0.2.64 - 192.0.2.79 and that your firewall's external IP address is 192.0.2.65. Your ISP has also told you that you should use a netmask of 255.255.255.0 (so your /28 is part of a larger /24). With this many IP addresses, you are able to subnet your /28 into two /29's and set up your network as shown in the following diagram. Here, the DMZ comprises the subnet 192.0.2.64/29 and the Local network is 192.0.2.72/29. The default gateway for hosts in the DMZ would be configured to 192.0.2.66 and the default gateway for hosts in the local network would be 192.0.2.73. Notice that this arrangement is rather wasteful of public IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses and 192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router. Nevertheless, it shows how subnetting can work and if we were dealing with a /24 rather than a /28 network, the use of 6 IP addresses out of 256 would be justified because of the simplicity of the setup. The astute reader may have noticed that the Firewall/Router's external interface is actually part of the DMZ subnet (192.0.2.64/29). What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The routing table on DMZ 1 will look like this: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.0.2.64 0.0.0.0 255.255.255.248 U 40 0 0 eth0 0.0.0.0 192.0.2.66 0.0.0.0 UG 40 0 0 eth0 This means that DMZ 1 will send an ARP who-has 192.0.2.65 request and no device on the DMZ Ethernet segment has that IP address. Oddly enough, the firewall will respond to the request with the MAC address of its DMZ Interface!! DMZ 1 can then send Ethernet frames addressed to that MAC address and the frames will be received (correctly) by the firewall/router. It is this rather unexpected ARP behavior on the part of the Linux Kernel that prompts the warning earlier in this guide regarding the connecting of multiple firewall/router interfaces to the same hub or switch. When an ARP request for one of the firewall/router's IP addresses is sent by another system connected to the hub/switch, all of the firewall's interfaces that connect to the hub/switch can respond! It is then a race as to which here-is response reaches the sender first.
Non-routed If you have the above situation but it is non-routed, you can configure your network exactly as described above with one additional twist; simply specify the proxyarp option on all three firewall interfaces in the /etc/shorewall/interfaces file. Most of us don't have the luxury of having enough public IP addresses to set up our networks as shown in the preceding example (even if the setup is routed). For the remainder of this section, assume that your ISP has assigned you IP addresses 192.0.2.176-180 and has told you to use netmask 255.255.255.0 and default gateway 192.0.2.254. Clearly, that set of addresses doesn't comprise a subnetwork and there aren't enough addresses for all of the network interfaces. There are four different techniques that can be used to work around this problem. Source Network Address Translation (SNAT). Destination Network Address Translation (DNAT) also known as Port Forwarding. Proxy ARP. Network Address Translation (NAT) also referred to as One-to-one NAT. Often a combination of these techniques is used. Each of these will be discussed in the sections that follow.
SNAT With SNAT, an internal LAN segment is configured using RFC 1918 addresses. When a host A on this internal segment initiates a connection to host B on the Internet, the firewall/router rewrites the IP header in the request to use one of your public IP addresses as the source address. When B responds and the response is received by the firewall, the firewall changes the destination address back to the RFC 1918 address of A and forwards the response back to A. Let's suppose that you decide to use SNAT on your local zone and use public address 192.0.2.176 as both your firewall's external IP address and the source IP address of Internet requests sent from that zone. The local zone has been subnetted as 192.168.201.0/29 (netmask 255.255.255.248). The systems in the local zone would be configured with a default gateway of 192.168.201.1 (the IP address of the firewall's local interface). SNAT is configured in Shorewall using the /etc/shorewall/masq file. #INTERFACE SUBNET ADDRESS eth0 192.168.201.0/29 192.0.2.176 This example used the normal technique of assigning the same public IP address for the firewall external interface and for SNAT. If you wanted to use a different IP address, you would either have to use your distributions network configuration tools to add that IP address to the external interface or you could set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf and Shorewall will add the address for you.
DNAT When SNAT is used, it is impossible for hosts on the Internet to initiate a connection to one of the internal systems since those systems do not have a public IP address. DNAT provides a way to allow selected connections from the Internet. Suppose that your daughter wants to run a web server on her system Local 3. You could allow connections to the Internet to her server by adding the following entry in /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT(S) PORT(S) DEST DNAT net loc:192.168.201.4 tcp www If one of your daughter's friends at address A wants to access your daughter's server, she can connect to http://192.0.2.176 (the firewall's external IP address) and the firewall will rewrite the destination IP address to 192.168.201.4 (your daughter's system) and forward the request. When your daughter's server responds, the firewall will rewrite the source address back to 192.0.2.176 and send the response back to A. This example used the firewall's external IP address for DNAT. You can use another of your public IP addresses (place it in the ORIGINAL DEST column in the rule above) but Shorewall will not add that address to the firewall's external interface for you. 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.
Proxy ARP The idea behind Proxy ARP is that: A host H behind your firewall is assigned one of your public IP addresses (A), and is assigned the same netmask (M) as the firewall's external interface. The firewall responds to ARP who has requests for A from machines outside of the firewall. When H issues an ARP who has request for a machine with an address in the network defined by M where the target machine is outside of the firewall, the firewall will respond to H (with the MAC of the firewall interface that H is connected to). For a more complete description of how Proxy ARP works, please see the Shorewall Proxy Documentation. Let us suppose that we decide to use Proxy ARP on the DMZ in our example network. Here, we've assigned the IP addresses 192.0.2.177 to system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface on the firewall. That address and netmask isn't relevant - just be sure it doesn't overlap another subnet that you've defined. The Shorewall configuration of Proxy ARP is done using the/etc/shorewall/proxyarp file. #ADDRESS INTERFACE EXTERNAL HAVE ROUTE PERSISTENT 192.0.2.177 eth2 eth0 No 192.0.2.178 eth2 eth0 No Because the HAVE ROUTE column contains No, Shorewall will add host routes thru eth2 to 192.0.2.177 and 192.0.2.178. The Ethernet interfaces on DMZ 1 and DMZ 2 should be configured to have the IP addresses shown but should have the same default gateway as the firewall itself -- namely 192.0.2.254. In other words, they should be configured just like they would be if they were parallel to the firewall rather than behind it. Do not add the Proxy ARP'ed address(es) (192.0.2.177 and 192.0.2.178 in the above example) to the external interface (eth0 in this example) of the firewall. 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 Proxy ARP, it will probably be HOURS before that system can communicate with the Internet. There are a couple of things that you can try: (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP Illustrated, Vol 1 reveals 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 proxy ARP (or one-to-one NAT 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 exampleStevens 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.
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.
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 192.0.2.177. On the firewall, run tcpdump as follows: tcpdump -nei eth0 icmp Now from 192.0.2.177, ping the ISP's gateway (which we will assume is 192.0.2.254): ping 192.0.2.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: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF) 13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo replyNotice 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 DMZ 1. In other words, the gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ 1 rather than with the firewall's eth0.
One-to-one NAT With one-to-one NAT, you assign local systems RFC 1918 addresses then establish a one-to-one mapping between those addresses and public IP addresses. For outgoing connections SNAT (Source Network Address Translation) occurs and on incoming connections DNAT (Destination Network Address Translation) occurs. Let's go back to our earlier example involving your daughter's web server running on system Local 3. Recall that in this setup, the local network is using SNAT and is sharing the firewall external IP (192.0.2.176) for outbound connections. This is done with the following entry in /etc/shorewall/masq: #INTERFACE SUBNET ADDRESS eth0 192.168.201.0/29 192.0.2.176 Suppose now that you have decided to give your daughter her own IP address (192.0.2.179) for both inbound and outbound connections. You would do that by adding an entry in /etc/shorewall/nat. #EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 192.0.2.179 eth0 192.168.201.4 No No With this entry in place, you daughter has her own IP address and the other two local systems share the firewall's IP address. Once the relationship between 192.0.2.179 and 192.168.201.4 is established by the nat file entry above, it is no longer appropriate to use a DNAT rule for you daughter's web server -- you would rather just use an ACCEPT rule: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT(S) PORT(S) DEST ACCEPT net loc:192.168.201.4 tcp www 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. There are a couple of things that you can try: (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP Illustrated, Vol 1 reveals 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. 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 exampleStevens 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.
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.
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 192.0.2.177. On the firewall, run tcpdump as follows: tcpdump -nei eth0 icmp Now from 192.0.2.177, ping the ISP's gateway (which we will assume is 192.0.2.254): ping 192.0.2.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: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF) 13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo replyNotice 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 DMZ 1. In other words, the gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ 1 rather than with the firewall's eth0.
Rules Shorewall has a macro facility that includes macros for many standard applications. This section does not use those macros but rather defines the rules directly. With the default policies described earlier in this document, your local systems (Local 1-3) can access any server on the Internet and the DMZ can't access any other host (including the firewall). With the exception of DNAT rules which cause address translation and allow the translated connection request to pass through the firewall, the way to allow connection requests through your firewall is to use ACCEPT rules. Since the SOURCE PORT(S) and ORIG. DEST. Columns aren't used in this section, they won't be shown You probably want to allow ping between your zones: #ACTION SOURCE DEST PROTO DEST # PORT(S) ACCEPT net dmz icmp echo-request ACCEPT net loc icmp echo-request ACCEPT dmz loc icmp echo-request ACCEPT loc dmz icmp echo-request Let's suppose that you run mail and pop3 servers on DMZ 2 and a Web Server on DMZ 1. The rules that you would need are: #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz:192.0.2.178 tcp smtp #Mail from #Internet ACCEPT net dmz:192.0.2.178 tcp pop3 #Pop3 from #Internet ACCEPT loc dmz:192.0.2.178 tcp smtp #Mail from local #Network ACCEPT loc dmz:192.0.2.178 tcp pop3 #Pop3 from local #Network ACCEPT $FW dmz:192.0.2.178 tcp smtp #Mail from the #Firewall ACCEPT dmz:192.0.2.178 net tcp smtp #Mail to the #Internet ACCEPT net dmz:192.0.2.177 tcp http #WWW from #Internet ACCEPT net dmz:192.0.2.177 tcp https #Secure WWW #from Internet ACCEPT loc dmz:192.0.2.177 tcp https #Secure WWW #from local #Network If you run a public DNS server on 192.0.2.177, you would need to add the following rules: #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz:192.0.2.177 udp domain #UDP DNS from #Internet ACCEPT net dmz:192.0.2.177 tcp domain #TCP DNS from #Internet ACCEPT loc dmz:192.0.2.177 udp domain #UDP DNS from #Local Network ACCEPT loc dmz:192.0.2.177 tcp domain #TCP DNS from #Local Network ACCEPT $FW dmz:192.0.2.177 udp domain #UDP DNS from #the Firewall ACCEPT $FW dmz:192.0.2.177 tcp domain #TCP DNS from #the Firewall ACCEPT dmz:192.0.2.177 net udp domain #UDP DNS to #the Internet ACCEPT dmz:192.0.2.177 net tcp domain #TCPP DNS to #the Internet You probably want some way to communicate with your firewall and DMZ systems from the local network -- I recommend SSH which through its scp utility can also do publishing and software update distribution. #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT loc dmz tcp ssh #SSH to the DMZ ACCEPT net $FW tcp ssh #SSH to the #Firewall
Odds and Ends The above discussion reflects my personal preference for using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I prefer to use NAT only in cases where a system that is part of an RFC 1918 subnet needs to have its own public IP. If you haven't already, it would be a good idea to browse through /etc/shorewall/shorewall.conf just to see if there is anything there that might be of interest. You might also want to look at the other configuration files that you haven't touched yet just to get a feel for the other things that Shorewall can do. In case you haven't been keeping score, here's the final set of configuration files for our sample network. Only those that were modified from the original installation are shown. /etc/shorewall/interfaces (The options will be very site-specific). #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect routefilter loc eth1 detect dmz eth2 detect The setup described here requires that your network interfaces be brought up before Shorewall can start. This opens a short window during which you have no firewall protection. If you replace detect with the actual broadcast addresses in the entries above, you can bring up Shorewall before you bring up your network interfaces. #ZONE INTERFACE BROADCAST OPTIONS net eth0 192.0.2.255 loc eth1 192.168.201.7 dmz eth2 192.168.202.7 /etc/shorewall/masq - Local Subnet #INTERFACE SUBNET ADDRESS eth0 192.168.201.0/29 192.0.2.176 /etc/shorewall/proxyarp - DMZ #ADDRESS EXTERNAL INTERFACE HAVE ROUTE 192.0.2.177 eth2 eth0 No 192.0.2.178 eth2 eth0 No /etc/shorewall/nat- Daughter's System #EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 192.0.2.179 eth0 192.168.201.4 No No /etc/shorewall/rules #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) ACCEPT net dmz icmp echo-request ACCEPT net loc icmp echo-request ACCEPT dmz loc icmp echo-request ACCEPT loc dmz icmp echo-request ACCEPT net loc:192.168.201.4 tcp www #Daughter's #Server ACCEPT net dmz:192.0.2.178 tcp smtp #Mail from #Internet ACCEPT net dmz:192.0.2.178 tcp pop3 #Pop3 from #Internet ACCEPT loc dmz:192.0.2.178 tcp smtp #Mail from local #Network ACCEPT loc dmz:192.0.2.178 tcp pop3 #Pop3 from local #Network ACCEPT $FW dmz:192.0.2.178 tcp smtp #Mail from the #Firewall ACCEPT dmz:192.0.2.178 net tcp smtp #Mail to the #Internet ACCEPT net dmz:192.0.2.177 tcp http #WWW from #Internet ACCEPT net dmz:192.0.2.177 tcp https #Secure WWW #from Internet ACCEPT loc dmz:192.0.2.177 tcp https #Secure WWW #from local #Network ACCEPT net dmz:192.0.2.177 udp domain #UDP DNS from #Internet ACCEPT net dmz:192.0.2.177 tcp domain #TCP DNS from #Internet ACCEPT loc dmz:192.0.2.177 udp domain #UDP DNS from #Local Network ACCEPT loc dmz:192.0.2.177 tcp domain #TCP DNS from #Local Network ACCEPT $FW dmz:192.0.2.177 udp domain #UDP DNS from #the Firewall ACCEPT $FW dmz:192.0.2.177 tcp domain #TCP DNS from #the Firewall ACCEPT dmz:192.0.2.177 net udp domain #UDP DNS to #the Internet ACCEPT dmz:192.0.2.177 net tcp domain #TCPP DNS to #the Internet ACCEPT loc dmz tcp ssh #SSH to the DMZ ACCEPT net $FW tcp ssh #SSH to the #Firewall
DNS Given the collection of RFC 1918 and public addresses in this setup, it only makes sense to have separate internal and external DNS servers. You can combine the two into a single BIND 9 server using Views. If you are not interested in Bind 9 views, you can go to the next section. Suppose that your domain is foobar.net and you want the two DMZ systems named www.foobar.net and mail.foobar.net and you want the three local systems named "winken.foobar.net, blinken.foobar.net and nod.foobar.net. You want your firewall to be known as firewall.foobar.net externally and its interface to the local network to be know as gateway.foobar.net and its interface to the dmz as dmz.foobar.net. Let's have the DNS server on 192.0.2.177 which will also be known by the name ns1.foobar.net. The /etc/named.conf file would look like this: options { directory "/var/named"; listen-on { 127.0.0.1 ; 192.0.2.177; }; transfer-format many-answers; max-transfer-time-in 60; allow-transfer { // Servers allowed to request zone transfers <secondary NS IP>; }; }; logging { channel xfer-log { file "/var/log/named/bind-xfer.log"; print-category yes; print-severity yes; print-time yes; severity info; }; category xfer-in { xfer-log; }; category xfer-out { xfer-log; }; category notify { xfer-log; }; }; # # This is the view presented to our internal systems # view "internal" { # # These are the clients that see this view # match-clients { 192.168.201.0/29; 192.168.202.0/29; 127.0.0.0/8; 192.0.2.176/32; 192.0.2.178/32; 192.0.2.179/32; 192.0.2.180/32; }; # # If this server can't complete the request, it should use # outside servers to do so # recursion yes; zone "." in { type hint; file "int/root.cache"; }; zone "foobar.net" in { type master; notify no; allow-update { none; }; file "int/db.foobar"; }; zone "0.0.127.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.127.0.0"; }; zone "201.168.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.192.168.201"; }; zone "202.168.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "int/db.192.168.202"; }; zone "176.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.176"; }; zone "177.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.177"; }; zone "178.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.192.0.2.178"; }; zone "179.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; file "db.206.124.146.179"; }; }; # # This is the view that we present to the outside world # view "external" { match-clients { any; }; # # If we can't answer the query, we tell the client so # recursion no; zone "foobar.net" in { type master; notify yes; allow-update {none; }; file "ext/db.foobar"; }; zone "176.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.176"; }; zone "177.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.177"; }; zone "178.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.178"; }; zone "179.2.0.192.in-addr.arpa" in { type master; notify yes; allow-update { none; }; file "db.192.0.2.179"; }; }; Here are the files in /var/named (those not shown are usually included in your bind distribution). db.192.0.2.176 - This is the reverse zone for the firewall's external interface ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32 ; Filename: db.192.0.2.176 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Inverse Address Arpa Records (PTR's) ; ############################################################ 176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net. db.192.0.2.177 - Reverse zone www server ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32 ; Filename: db.192.0.2.177 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Inverse Address Arpa Records (PTR's) ; ############################################################ 177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net. db.192.0.2.178 - Reverse zone for the mail server ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32 ; Filename: db.192.0.2.178 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Inverse Address Arpa Records (PTR's) ; ############################################################ 178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net. db.192.0.2.179 - Reverse zone for Daughter's public web server ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32 ; Filename: db.192.0.2.179 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001102303 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. @ 604800 IN NS <name of secondary ns>. ; ; ############################################################ ; Inverse Address Arpa Records (PTR's) ; ############################################################ 179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net. int/db.127.0.0 - Reverse zone for localhost ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8 ; Filename: db.127.0.0 ; ############################################################ @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2001092901 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. ; ############################################################ ; Inverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR localhost.foobar.net. int/db.192.168.201 - Reverse zone for the local network. This is only shown to internal clients. ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29 ; Filename: db.192.168.201 ; ############################################################ @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. ( 2002032501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. ; ############################################################ ; Inverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR gateway.foobar.net. 2 86400 IN PTR winken.foobar.net. 3 86400 IN PTR blinken.foobar.net. 4 86400 IN PTR nod.foobar.net. int/db.192.168.202 - Reverse zone for the firewall's DMZ Interface ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29 ; Filename: db.192.168.202 ; ############################################################ @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. ( 2002032501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ; ############################################################ ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. ; ############################################################ ; Inverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR dmz.foobar.net. int/db.foobar - Forward zone for internal clients. ;############################################################## ; Start of Authority for foobar.net. ; Filename: db.foobar ;############################################################## @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2002071501 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ); minimum (1 day) ;############################################################ ; foobar.net Nameserver Records (NS) ;############################################################ @ 604800 IN NS ns1.foobar.net. ;############################################################ ; Foobar.net Office Records (ADDRESS) ;############################################################ localhost 86400 IN A 127.0.0.1 firewall 86400 IN A 192.0.2.176 www 86400 IN A 192.0.2.177 ns1 86400 IN A 192.0.2.177 mail 86400 IN A 192.0.2.178 gateway 86400 IN A 192.168.201.1 winken 86400 IN A 192.168.201.2 blinken 86400 IN A 192.168.201.3 nod 86400 IN A 192.168.201.4 dmz 86400 IN A 192.168.202.1 ext/db.foobar - Forward zone for external clients. ;############################################################## ; Start of Authority for foobar.net. ; Filename: db.foobar ;############################################################## @ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. ( 2002052901 ; serial 10800 ; refresh (3 hour) 3600 ; retry (1 hour) 604800 ; expire (7 days) 86400 ); minimum (1 day) ;############################################################ ; Foobar.net Nameserver Records (NS) ;############################################################ @ 86400 IN NS ns1.foobar.net. @ 86400 IN NS <secondary NS>. ;############################################################ ; Foobar.net Foobar Wa Office Records (ADDRESS) ;############################################################ localhost 86400 IN A 127.0.0.1 ; ; The firewall itself ; firewall 86400 IN A 192.0.2.176 ; ; The DMZ ; ns1 86400 IN A 192.0.2.177 www 86400 IN A 192.0.2.177 mail 86400 IN A 192.0.2.178 ; ; The Local Network ; nod 86400 IN A 192.0.2.179 ;############################################################ ; Current Aliases for foobar.net (CNAME) ;############################################################ ;############################################################ ; foobar.net MX Records (MAIL EXCHANGER) ;############################################################ foobar.net. 86400 IN A 192.0.2.177 86400 IN MX 0 mail.foobar.net. 86400 IN MX 1 <backup MX>.
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 the Firewall The Installation procedure configures your system to start Shorewall at system boot. 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. A running firewall may be restarted using the shorewall restart command. If you want to totally remove any trace of Shorewall from your Netfilter configuration, use shorewall clear. Edit the /etc/shorewall/routestopped file and configure those systems that you want to be able to access the firewall when it is stopped. If you are connected to your firewall from the Internet, do not issue a shorewall stop command unless you have added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. Also, I don't recommend using shorewall restart; it is better to create an an alternate configuration and test it using the shorewall try command.
shorewall-docs-xml-4.5.21/GenericTunnels.xml0000644000175000017500000001056412222401136020671 0ustar teastepteastep
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-4.5.21/ReleaseModel.xml0000644000175000017500000001142212222401136020277 0ustar teastepteastep
Shorewall Release Model Tom Eastep 2004 2005 2006 2007 2008 2009 2010 2012 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.
Shorewall Releases Releases have a three-level identification x.y.z (e.g., 4.5.0). The first two levels (x.y) designate the major release number (e.g., 4.5). The third level (y) designates the minor release Number. Installing a new minor release involves no migration issues unless you want to take advantage of an enhancement. For example, if you are running 4.5.0 and I release 4.5.1, your current configuration is 100% compatible with the new release. A major release may have migration issues. These are listed in the release notes and on the upgrade issues page. Support is available through the Mailing List for the most recent Major Release. After the introduction of a new major release, support is still available for the prior major release until the principle distributions have upgraded to that new release. Fixes will only be provided for the last minor release in the previous Major Release. For example, once 4.5.0 was released, the only fixes for major issues with 4.4.27 would be released for the 4.4 series. Support for the prior major release ends once the major Linux distributions have upgraded to that release. Once a minor release has been announced, work begins on the next minor release. Periodic Beta releases are made available through announcements on the Shorewall Development and Shorewall User mailing lists. Those Beta releases are numberd w.x.y-Beta1, ...Beta2, etc. Support for the Beta releases is offered through the Shorewall Development mailing list in the form of emailed patches. There is no guarantee of compatability between one Beta release and the next as features are tweaked. When the next minor release is functionally complete, one or more release candidates are announced on the Shorewall Development and Shorewall User mailing lists. These release candidates are numbered w.x.y-RC1, ...-RC2, etc. What does it mean for a major release to be supported? It means that that if a bug is found, we will fix the bug and include the fix in the next minor release. Between minor releases, bug fixes are made available via patch releases. A patch release has a four-level identification x.y.z.N where x.y.z is the minor release being fixed and N = 1.2.3... The currently-supported major release 4.5.
shorewall-docs-xml-4.5.21/images/0000755000175000017500000000000012223303501016457 5ustar teastepteastepshorewall-docs-xml-4.5.21/images/Xen4a.vdx0000755000175000017500000223767712222401136020216 0ustar teastepteastep TEastepHewlett-Packard738201805738203013 AQAAAIwAAAAAAAAAAAAAAGAAAABGAAAAAAAAAAAAAACMCgAANgcAACBFTUYAAAEAKFIAAAMAAAABA AAADwAAAGwAAAAAAAAAAAUAAAAEAABoAQAADgEAAAAAAAAAAAAAAAAAAEB+BQCwHgQAVgBJAFMASQ BPAAAARAByAGEAdwBpAG4AZwAAAAAAAABMAAAAiFEAAAAAAAAAAAAAYAAAAEYAAAAAAAAAAAAAAGE AAABHAAAAIADMAAAAAAAAAAAAAACAPwAAAAAAAAAAAACAPwAAAAAAAAAA////AAAAAABkAAAAKAAA AIwAAAD8UAAAKAAAAGEAAABHAAAAAQAYAAAAAAD8UAAAAAAAAAAAAAAAAAAAAAAAAP/////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////wD/////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////8A/// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// AP/////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////wD/////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////8A/////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////AP////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////wD////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////8A////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////AP///////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////wD//////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////8A//////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////AP///////////////////////////////wAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA P///////////////////////////wD///////////////////////////////8AAAAA/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/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8Az P8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP8AzP 8AAAD///////////////////////////8A////////////////////////////////AAAAAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAMz/AMz/AMz/AMz/AMz/AMz/AAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAMz/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/AAAAAA D/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAD/AAD/AAD/AAAAAAAAAADM/wDM/wDM/wDM/wDM/wDM/wA AAOPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPR xgAAAADM/wAAAP///////////////////////////wD///////////////////////////////8AA AAA/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/wAAAAA A/wAAAAAA/wAAAAAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAzP8AzP8AzP8AzP8AzP8A zP8AAADj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0 cbj0cYAAAAAzP8AAAD///////////////////////////8A////////////////////////////// //AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAA AP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP8AAP8AAAAAAAAAAMz/AMz/AMz/AMz/A Mz/AMz/AAAA49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49 HG49HG49HGAAAAAMz/AAAA////////////////////////////AP///////////////////////// //////wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AHM3NwD/AAD/AAD/AAD/AHM3NwD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAP///////wAAAAAAAAAAAAAAAAD/AAD/AAD/AAD/AAD/A AD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAD/AAD/AAAAAAAAAADM/wDM/wDM/w DM/wDM/wDM/wAAAOPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuP RxuPRxuPRxuPRxgAAAADM/wAAAP///////////////////////////wD///////////////////// //////////8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wBzNzcA/wAA/wAA/wAA/wBzNzcA/wAA/wAA/ wAA/wAA/wAA/wAA/wAAAAAAAAD///////////////////////////////////8AAAAAAAAA/wAA/w AA/wAA/wAA/wAA/wAAAAAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAzP8AzP8 AzP8AzP8AzP8AzP8AAADj0cbj0cbj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj 0cbj0cbj0cbj0cbj0cYAAAAAzP8AAAD///////////////////////////8A///////////////// /////////////// AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8Aczc3AP8AAP8AAP8AAP8Aczc3AP8AAP8AAP8AAP8AAP8AA P8AAAAA////////////////////////////////////////////////AAAAAAAAAP8AAP8AAP8AAA AAAAAAAAAA////AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAMz/AMz/AMz/AMz/AMz /AMz/AAAA49HG49HG49HG49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HG49HG 49HG49HGAAAAAMz/AAAA////////////////////////////AP/////////////////////////// ////wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AHM3NwD/AAD/AAD/AAD/AHM3NwD/AAD/AAD/AAD/AA D/AAAAAAAAAP///////////////wAAAP///wAAAP///wAAAP///////////////wAAAAD/AAD/AAD /AAAAAOzs7Ozs7AAAAAAAAAAAAAAAAN3d3d3d3QD/AAD/AAD/AAD/AAAAAAAAAADM/wDM/wAAAADM /wAAAADM/wAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAA OPRxuPRxuPRxgAAAADM/wAAAP///////////////////////////wD/////////////////////// ////////8AAAAA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAA/wAA/wAAAAD///////////////////8AAAD///8AAAD///////////////////8AAAAA/wAA /wAA/wAA/wAAAAAAAAD///////8AAADLy8sAAAAAAAAA/wAA/wAA/wAA/wAAAAAAAAAAzP8AAAAAz P8AAAAAzP8AzP8AAADj0cbj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAA Dj0cbj0cbj0cbj0cYAAAAAzP8AAAD///////////////////////////8A/////////////////// /////////////AAAAAP8AAP8AAP8AAAAA38q538q538q538q5AAAA38q5AAAA38q538q538q538q5 czc3AAAAAP8AAP8AAAAA////////AAAA////AAAA////AAAA////AAAA////AAAA////////AAAAA P8AAP8AAP8AAP8AAP8AAAAAAAAAAAAAAAAA////////AAAAAP8AAP8AAP8AAP8AAAAAAAAAAMz/AM z/AAAAAMz/AAAAAMz/AAAA49HG49HG49HG49HG49HG49HG49HGAAAA49HGAAAA49HG49HG49HG49H G49HG49HG49HG49HG49HGAAAAAMz/AAAA////////////////////////////AP////////////// /////////////////wAAAAD/AAD/AAD/AAAAANvAqNvAqNvAqNvAqNvAqAAAANvAqAAAANvAqNvAq NvAqHM3NwAAAAD/AAD/AAAAAP///////////////////////////////////////////////wAAAA AAAAD/AAD/AAD/AAD/AAD/AAAAAAAAAPn18wAAAP///wAAAAD/AAD/AAD/AAD/AAD/AAAAAAAAAAD M/wAAAADM/wAAAADM/wDM/wAAAOPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxgAAAOPRxuPRxuPRxuPR xuPRxuPRxuPRxuPRxuPRxuPRxgAAAADM/wAAAP///////////////////////////wD////////// /////////////////////8AAAAA/wAA/wAA/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA/wAA/wAA/wAA/wAAAAD///////////////////////////////////////8AAAA A/wAA/wAA/wAA/wAA/wAA/wAA/wAAAAAAAAAAAAAAAAD///8AAAAA/wAA/wAA/wAA/wAA/wAAAAAA AAAAzP8AzP8AzP8AzP8AzP8AzP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzP8AzP8AAAD///////////////////////////8A////// //////////////////////////AAAAAP8AAP8AAP8AAP8AAP8Aczc3AP8AAP8AAP8AAP8Aczc3AP8 AAP8AAP8Aczc3AP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAA////////////////////////////AAAA AAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAAAAAAAAAAAAAAAAAAAAAP8AAP8AAP8AAP8AAP8AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////////////////AP/ //////////////////////////////wAAAAD/AAD/AAD/AAD/AAD/AHM3NwD/AAD/AAD/AAD/AHM3 NwD/AAD/AAD/AHM3NwD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAAAAAAAAAD/AAD/AAD/AAD/AAD/AAD/AA D/AAAAAP///////////////////////////////////////////////////////////////wAAAP/ ///////////////////////////////////////////////////////////////////////////// /wD///////////////////////////////8AAAAA/wAA/wAA/wAA/wAA/wBzNzcA/wAA/wAA/wAA/ wBzNzcA/wAA/wAA/wBzNzcA/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/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD////////////////////// /////8A////////////////////////////////AAAAAP8AAP8AAAAAAP8AAAAAAP8AAP8AAP8AAP 8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAAAAAAAA49HG49HG49HG49HG49HG49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGA AAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HG49HG49HG49HG49HGAAAA////////////////// //////////AP///////////////////////////////wAAAAD/AAD/AAD/AAAAAAD/AAAAAAD/AAD /AAD/AAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/ AAAAAAAAAOPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRx uPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxgAAAP///////////////////////////w D///////////////////////////////8AAAAA/wAA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/wAA/wA AAAAA/wAA/wAA/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/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAADj0cbj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0c YAAADj0cYAAADj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYAAAD//////////////////////// ///8A////////////////////////////////AAAAAP8AAP8AAP8AAAAAAP8AAAAAAP8AAP8AAP8A AP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAAAAAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49H GAAAA49HGAAAA49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGAAAA//////////////////// ////////AP///////////////////////////////wAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAAAA D/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAAAAAAAAOPRxuPRxgAAAOPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPR xuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxgAAAP/////////////// ////////////wD///////////////////////////////8AAAAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAAAAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0 cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYAAAD/////////// ////////////////8A////////////////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA49HG49HG49HG49HG49HG49HGAAAA49HGAAAA49HGAAAA49 HGAAAA49HGAAAA49HGAAAA49HGAAAA49HG49HG49HG49HG49HG49HG49HG49HG49HGAAAA/////// /////////////////////AP////////////////////////////////////////////////////// /////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOPRxgAAAOPRxgAAAOPRxuPRxuPRxuPRxuPRxuPRxuP RxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxgAAAP// /////////////////////////wD///////////////////////////////8AAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADj0cbj0cYAAADj0cbj0cbj0cbj0cbj0cbj0cbj 0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYAA AD///////////////////////////8A////////////////////////////////AAAAwo5Owo5Owo 5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5 Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5O wo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5OAAAAAAAA49HG49HG49HG49HG49HG49HG49HG49HG4 9HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49 HGAAAA////////////////////////////AP///////////////////////////////wAAAMKOTsK OTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKO TsKOTsKOTgAAAAAAAAAAAAAAAAAAAAAAAMKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOT sKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTgAAAAAAAOPRxuPRxuPRxuPRxuPRxuPRxuPRxu PRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuP RxuPRxgAAAP///////////////////////////wD///////////////////////////////8AAADC jk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk4AAAAAA AAAAAAAAAAAAAD///////////////////////8AAAAAAAAAAADCjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk 7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk4AAAAAAADj0cbj0cbj0cbj0cbj0cbj0cb j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj 0cbj0cbj0cYAAAD///////////////////////////8A////////////////////////////////A AAAwo5Owo5OAAAA wo5OAAAAwo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5OAAAAAAAAAAAAAAAA////////////A AAA////AAAA////AAAA////////////////////AAAAAAAAwo5Owo5Owo5Owo5Owo5Owo5Owo5Owo 5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5OAAAAAAAA49HG49HG49HG49HG49HG49HG49HG49HG49H G49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG AAAA////////////////////////////AP///////////////////////////////wAAAMKOTsKOT sKOTgAAAMKOTgAAAMKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTgAAAP//////////////////// ///////wAAAP///wAAAP///////////////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAA AOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRx uPRxgAAAP///////////////////////////wD///////////////////////////////8AAADCjk 7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk4AAAD///////////////8 AAAD///8AAAD///8AAAD///8AAAD///8AAAD///////////////8AAADCjk7Cjk7Cjk7Cjk7Cjk7C jk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk4AAAAAAADj0cbj0cbj0cbj0cbj0cbj0cbj0 cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0c bj0cbj0cYAAAD///////////////////////////8A////////////////////////////////AAA Awo5Owo5Owo5OAAAAwo5OAAAAwo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5OAAAAAAAAAAAA ////////AAAA////AAAA////AAAA////AAAA////////////AAAAAAAAwo5Owo5Owo5Owo5Owo5Ow o5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5Owo5OAAAAAAAA49HG49HG49HG49HG49HG49 HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49H G49HG49HG49HGAAAA////////////////////////////AP////////////////////////////// /wAAAMKOTsKOTgAAAMKOTgAAAMKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOT gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMKOTsKOTsKOTsKOTsKOTsKOTs KOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTsKOTgAAAAAAAOPRxuPRxuPRxuPRxuP RxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPR xuPRxuPRxuPRxuPRxgAAAP///////////////////////////wD////////////////////////// /////8AAADCjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk 7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7 Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk7Cjk4AAAAAAADj0cbj0cbj0cbj 0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0 cbj0cbj0cbj0cbj0cbj0cYAAAD///////////////////////////8A////////////////////// //////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA49HG49HG4 9HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49 HG49HG49HG49HG49HG49HG49HGAAAA////////////////////////////AP///////////////// //////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOPRxu PRxuPRxuPRxuPRxuPRxuPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOP RxgAAAOPRxuPRxuPRxuPRxuPRxuPRxgAAAP///////////////////////////wD///////////// //////////////////8AAAAA//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//8AAAAAAAD j0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj 0cYAAADj0cbj0cbj0cbj0cbj0cbj0cbj0cYAAAD///////////////////////////8A///////// ///////////////////////AAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP //AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//AP//AP/ /AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAA AAAA49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG4 9HG49HG49HG49HG49HG49HG49HG49HG49HG49HGAAAA////////////////////////////AP//// ///////////////////////////wAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD //wD//wD//wD//wD//wD//wAAAAAAAAAAAAAAAAAAAP///////////////////////////wAAAAAA AAAAAAAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD// wAAAAAAAOPRxuPR xuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRx uPRxuPRxuPRxuPRxuPRxuPRxuPRxgAAAP///////////////////////////wD/////////////// ////////////////8AAAAA//8A//8A//8AAAAA//8AAAAA//8A//8A//8A//8A//8A//8A//8A//8 A//8AAAAAAAD///////////////////////8AAAD///8AAAD///8AAAD///////////////8AAAAA AAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8AAAAAAADj0 cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0c bj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYAAAD///////////////////////////8A/////////// /////////////////////AAAAAP//AP//AAAAAP//AAAAAP//AP//AP//AP//AP//AP//AP//AP// AP//AP//AAAA////////////////////////AAAA////AAAA////AAAA///////////////////// ///AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA49HG49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HG49H G49HG49HG49HG49HG49HG49HG49HG49HG49HGAAAA////////////////////////////AP////// /////////////////////////wAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD// wD//wD//wD//wAAAP///////////wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///wAAAP//// ///////wAAAAAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wA AAAAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAA AOPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxgAAAP///////////////////////////wD// /////////////////////////////8AAAAA//8A//8AAAAA//8AAAAA//8A//8A//8A//8A//8A// 8A//8A//8A//8A//8A//8AAAAAAAAAAAD///8AAAD///8AAAD///8AAAD///8AAAD///8AAAD///8 AAAAAAAAAAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A //8AAAAAAADj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0 cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYAAAD/////////////////////////// 8A////////////////////////////////AAAAAP//AP//AP//AAAAAP//AAAAAP//AP//AP//AP/ /AP//AP//AP//AP//AP//AP//AP//AP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//A P//AP//AAAAAAAA49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49 HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGAAAA/////////////////////// /////AP///////////////////////////////wAAAAD//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//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//w D//wD//wD//wAAAAAAAOPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuP RxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxgAAAP////////////////// /////////wD///////////////////////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYA AADj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYAAAD////////////// /////////////8A////////////////////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA////AAAA49HG49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGA AAA49HGAAAA49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGAAAA////////// //////////////////AP///////////////////////////////wAAAABm/wBm/wBm/wBm/wBm/wB m/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm /wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/ wBm/wBm/wBm/wBm/wBm/wBm/wAAAAAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxg AAAOPRxgAAAOPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxgAAAP///// //////////////////////wD///////////////////////////////8AAAAAZv8AZv8AZv8AZv8A Zv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv 8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AAAAAAADj0cbj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cY AAADj0cYAAADj0cYAAADj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYAAAD/ //////////////////////////8A////////////////////////////////AAAAAGb/AGb/AGb/A Gb/AGb/AGb/AGb/ AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AAAAAAAAAAAAAAAA///////////////////////// ///////////////////AAAAAAAAAGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AG b/AGb/AGb/AGb/AGb/AAAAAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49HGAAAA49H GAAAA49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGAAAA//////////// ////////////////AP///////////////////////////////wAAAABm/wBm/wBm/wBm/wBm/wBm/ wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wAAAAAAAP//////////////////////////////// ///////////////////////////////wAAAABm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wB m/wBm/wBm/wBm/wBm/wBm/wAAAAAAAOPRxuPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPRxgAAAOPR xgAAAOPRxgAAAOPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxgAAAP/////// ////////////////////wD///////////////////////////////8AAAAAZv8AZv8AZv8AZv8AZv 8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AAAD///////////////////////////8AAAD ///8AAAD///8AAAD///////////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0cYAAADj0 cYAAADj0cYAAADj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cYAAAD/// ////////////////////////8A////////////////////////////////AAAAAGb/AGb/AAAAAGb /AAAAAGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AAAA////////////////////////AAAA ////AAAA////AAAA////////////////////////AAAAAGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/A Gb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AAAAAAAA49HG49HGAAAA49HGAAAA49HGAAAA49HGAAAA49 HGAAAA49HGAAAA49HGAAAA49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HGAAA A////////////////////////////AP///////////////////////////////wAAAABm/wAAAABm /wAAAABm/wAAAABm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wAAAP/////////////////// ////////////////////////////////////////wAAAAAAAABm/wBm/wBm/wBm/wBm/wBm/wBm/w Bm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wBm/wAAAAAAAOPRxgAAAOPRxgAAAOPRxuPRxuPRxuPRxuP RxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPRxuPR xgAAAP///////////////////////////wD///////////////////////////////8AAAAAZv8AZ v8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AAAAAAAD/////// ////////////////////////////////8AAAAAAAAAAAAAZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8 AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AZv8AAAAAAADj0cbj0cYAAADj0cbj0cbj0cbj0cbj 0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0cbj0 cbj0cYAAAD///////////////////////////8A////////////////////////////////AAAAAG b/AGb/AGb/AAAAAGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/ AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AGb/AAAAAAAA49HG49HG49HG49HG49HG49HG4 9HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49HG49 HG49HG49HGAAAA////////////////////////////AP///////////////////////////////wA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAP///////////////////////////wD///////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////8ADgAAABQAAAAAAAAAEAAAABQAA AA=TC0104981610332005-12-30T06:50:452007-04-15T08:34:382007-04-15T08:34:302005-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-1103311100.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#dddddd1000000000111100.013888888888888890.013888888888888890.013888888888888890.01388888888888889100.5000.003333333333333334010200020400010.1111111111111111000000000000-1103311100.01#ffffff10200020#ffffff#a7a7a731#e0e0e010000000001000-1.2001000-1001110#ffffff#dfdfdf30#e4e4e4100000000010.01#ffffff10200020000-1.2001000-1001110#ffffff#c0c0c032#e1e1e1100000000010.01010200020000-1.2001000-10011100.0208333333333333301020002011100.0016666666666666670102000201940010000000.125-0.12501400010.16666666666666670000000000000103311100.010102000201#c6d1e335010000000.125-0.12501400010.1666666666666667000000000000-110330000001033118.50.125-0.12511200000100110000000000011010000.0984251968503940.0984251968503940.196850393700790.196850393700790.295275590551180.295275590551180.0984251968503940.0984251968503940.666666666666670.66666666666667000000.250.250.250.2511110000217Co&lor Schemes...000000Network2552000000025520000000Connector2550110011Connector08.752.353.51.71.750.850000#ffcc00#c0c0c01#dddddd100000000010000003.503.51.701.7008.93.8142857142857150.21.628571428571430.10.81428571428571500008.938.94.628571428571432000000001002202120100103310.10.8142857142857150.55555555555555560.24444444444444440.27777777777777780.122222222222222200000004000000000.09999999999999990.8142857142857150.10.814285714285715500Reposition Text10000.100.11.628571428571433.72.96.22.83.11.40000#00ff00#c0c0c01#dddddd100000000010000006.206.22.802.8004.6642857142857163.6151785714285725.4714285714285691.5696428571428562.7357142857142840.784821428571427900001.9285714285714322.8303571428571447.44.42000000001002202120100103311.9508928571428551.5696428571428550.55555555555555560.24444444444444440.27777777777777780.122222222222222201.9508928571428551.5696428571428551.9508928571428551.569642857142855500Reposition Text10000001.5696428571428555.4714285714285671.5696428571428555.3660714285714317.7046115288220540.9535714285714185-0.20.4767857142857093-0.100004.8892857142857217.8035087719298235.842857142857147.6057142857142840000020001002202220100103310.5756829573934791-0.0011027568922305220.55555555555555560.24444444444444440.27777777777777780.122222222222222200.5756829573934791-0.0011027568922305220.5756829573934791-0.001102756892230522500Reposition Text10000-0.0011027568922305220.9535714285714194-0.0011027568922305220.9535714285714194-0.19889724310776951.9285714285714322.8303571428571441.5428571428571380.42500000000000080.7714285714285690.2125-7.401486830834382E-17000000000.7714285714285690.21250.464100293968750.2333812988281250.2320501469843750.11669064941406257.401486830834382E-17000000000009Ethernet00001033110.25719428571428490.85000000000000160.25719428571428490.2125001Connect To Network Device0.5142342857142841-0.42500000000000080.51423428571428410.2125001Connect To Network Device1.028622857142854-0.42500000000000081.0286228571428540.2125001Connect To Network Device0.7714285714285690.85000000000000160.7714285714285690.2125001Connect To Network Device1.2857091428571390.85000000000000161.2857091428571390.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device1.1571428571428540.21251.1571428571428540.2125001Connect To Network Device0.38571428571428450.21250.38571428571428450.2125001Connect To Network Device0.106250.212500000.7714285714285690.212500001.5428571428571380.21250000400010.1944444444444444000000000000-11033LAN 0.7714285714285690.21249999999999621.5428571428571380.42500000000000080.7714285714285690.2125-7.401486830834382E-1700000000000000000001Ethernet0000103310.106250.212500001.5428571428571380.2125000010000.25719428571428490.85000000000000160.25719428571428490.21250.7714285714285690.212510000.5142342857142841-0.42500000000000080.51423428571428410.21250.7714285714285690.212510001.028622857142854-0.42500000000000081.0286228571428540.21250.7714285714285690.212510000.7714285714285690.85000000000000160.7714285714285690.21250.7714285714285690.212510001.2857091428571390.85000000000000161.2857091428571390.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.212510001.1571428571428540.21251.1571428571428540.21250.7714285714285690.212510000.38571428571428450.21250.38571428571428450.21250.7714285714285690.21250.7714285714285690.21251.5428571428571380.42500000000000080.7714285714285690.212500000000000001.4366071428571380.21251.5003571428571380.21251.4366071428571380.382500000000000700000.106250.42500000000000081.4366071428571380.42500000000000081.43660714285713801.5428571428571380.2125-1.570796326794920.1062500.106250.425000000000000800.2125-1.570796326794920.7714285714285690.21251.5428571428571380.42500000000000080.7714285714285690.212500000000010000.106250.42500000000000081.4366071428571380.42500000000000081.43660714285713801.5428571428571380.2125-1.570796326794920.1062500.106250.425000000000000800.2125-1.5707963267949292.352.41.31.20.650000#c6d1e3#c0c0c01#dddddd1000000000100000000000000001000010331400010.25000000000000-110330000002.402.41.301.300DomU - lists 8.92.7071428571428252.80.41.40.2000000000400010.1944444444444444000000000000-110330000002.802.80.400.400eth0 206.124.146.177/24 1.23.7285714285714311.20.79999999999999890.60.4000000000400010.25000000000000-110330000001.201.20.799999999999998900.799999999999998900loc zone 7.42.7517857142856841.20.79999999999999890.60.4000000000400010.25000000000000-110330000001.201.20.799999999999998900.799999999999998900dmz zone 8.24.62.20.41.10.2000000000400010.1944444444444444000000000000-11033000-1.2000000-1000000002.202.20.400.400eth1 3.92.71.81.20.90.599999999999999400000000000000000000100001033100.599999999999999400001.80.599999999999999400000.9000000.91.20000400010.1944444444444444000000000000-1103300000.038990339305182020.59871622421182750.064433848732866030.73496715311007530.0034834739844240010.668938345641335301.006281225721170.16042984716067210.88774809151257520.110004069946680.879604709929823201.006281225721170.32500765061973011.0185935676849710.18101780058817810.984937892074067101.006281225721170.46836298385238611.0864752270645710.36786463614986411.12357508871169101.006281225721140.62167694623578031.1316646542425510.53608645379568631.16049319564781901.006281225721140.86127297784264831.1601476993227430.74912764572018031.19560425636256701.0062812257211560.96192353905111831.1585526821760230.89115510700317641.19560425636256701.006281225721141.068689433606931.1604931956478191.033182568286191.195604256362567-0.447422793082041.1642313875673371.160633267770591.1316646542425511.1397031642484291.160493195647819-0.14242183717013741.5162047590523141.3477461512806271.0861225857546351.2723706501167251.161027591668747-0.19983428454115511.5161494343963051.4143336672995011.0421561222857791.4042777771535491.104848837233163-2.5093380433504471.5102202941712661.5728869211615830.93578240707342711.5361849041903911.04867008279757901.0062812257211561.6367992787389330.84449364921507521.6367992787389330.8796047099298232-0.17901668060573831.5158010057673961.7314032143869030.69233669013485931.7353663857811630.8142828734682233-3.0977079470492891.5168420359699351.7433198747011890.59871622421182751.7788267400219470.633827284926575401.5169093982613011.7367393533047570.52903636666143551.7999991582640570.561787544355839401.006281225721171.6798736139317830.38600901085677561.7433198747011890.423160920638087601.0062812257211861.6218803668456990.30968435691109171.7078130093804490.3178277384938437-3.1113933472870261.2688508175076571.4573025633866410.17883888073869581.6012924134181930.212494556349587801.006281225721171.3139472301539670.11095722135908391.4237580868144390.107161374205343901.5169093982613011.1752100295691870.072050313490595931.2817306255314430.0369392527758479601.006281225721171.0312501318300440.044582833038551961.1041962989276880.0018281920611-0.10275968385910541.3162147315683370.89115510700317640.036939252775847960.96216883764467440.001828192061101.5169093982613010.71735247742680030.048747568916507960.78463451104093830.001828192061101.5169093982613010.57159331911642620.10716137420534390.64260704975792430.03693925277584796-0.20840689985388731.5154135588072870.44324013731378420.14981001182822390.47749953615537620.08198159907476392-0.16944143384858961.7616552122644840.32304526187117420.24760561706433580.36786463614988210.149810011828223901.0062812257211560.18101780058817810.24760561706433580.23595750911304010.224715017742335801.006281225721170.10243660007457010.38600901085677560.110004069946680.3178277384938437-0.12905498695084461.5163300341537010.028674880912314010.52433504139878350.0034152122530980010.440018161229783601.0062812257211190.038990339305182020.59871622421182750.0098310056213340040.5617875443558394-0.20388099990277611.516044201302877Local Wireless Clients 5.453.73.10.79999999999999891.550.399999999999998600003.93.374.12000000001002202120100103311.150.79999999999999720.55555555555555560.24444444444444440.27777777777777780.122222222222222201.150.79999999999999811.150.7999999999999972500Reposition Text10000000.79999999999999813.10.79999999999999813.6785714285714267.8142857142857126.242857142857151.2285714285714253.1214285714285750.614285714285712600000000000000080000103313.1428571428571490.60350877192982426.21.2070175438596483.10.6035087719298240000#ff6600#c0c0c01#dddddd100000000010000006.206.21.20701754385964801.207017543859648003.157142857142870.60350877192982422.350.9052631578947361.1750.45263157894736800000000000000000000100001033100.45263157894736800002.350.45263157894736800001.175000001.1750.9052631578947360000400010.1944444444444444000000000000-1103300000.05090405409287650.45166311651067690.084121969179019510.55444890497777610.0045478688129980.504637699343463501.7414905708701660.2094500782375440.66970470061474960.143616424652610.663561447841796401.7414905708701660.42431554386464750.76841269141146940.23632879521234350.743023322090962901.7414905708701660.61147389558505950.81962166252239570.48026771941787810.847609277449170401.7414905708701140.81163379091893510.85371193214788930.69989064801103460.875459779172916101.7414905708701141.1244397210723460.875199141594350.9780277596902350.901947070589304801.741490570870141.2558446204278480.87399588304506991.1634525008097020.901947070589304801.7414905708701141.3952334272090470.87545977917291611.3488772419291920.9019470705893048-0.085050472991565921.9260979374031551.5152712107004920.85371193214788931.4879457977687810.8754597791729161-0.054419893651229912.6006617941182871.759557475283040.81935563486753171.6611505709857230.875862920030809-0.076382169673820282.5782181715300321.8464911767521250.78618795189979821.8333626535060210.833482456158351-2.9008159344284582.2003173649789062.0534912581831760.7059411141080242.0055747360263430.791101992285892801.741490570870142.1369323916869390.63707415642540772.1369323916869390.6635614478417964-0.068395993289519692.5865768465300122.2604430854495670.52228908203156062.2656172258809620.6142835712128701-3.124821816454962.6228513866486442.2760009475265510.45166311651067692.322357132806430.478150407927065702.6251939779987252.2674097112589870.39909760993757422.3499989010669620.423804638724580601.7414905708701662.1931683292998270.29119978012002372.2760009475265510.319226659428732701.7414905708701922.1174549233818830.2336215324066132.2296447622466960.2397647851795663-3.1332524481016642.1952612840845171.902589457754780.13491354160989342.0905762064070840.160302910930390801.7414905708701661.7154311060343440.083704570498958021.8587952800077390.0808410366812243502.6251939779987251.534301983048660.054353745264835531.6733705388882720.0278664538484467101.7414905708701661.3463543387781130.033632663520311131.4415896124889260.001379162432057893-0.031066420889536752.2694989299172531.1634525008097020.027866453848446711.2561648713694360.00137916243205789302.6251939779987250.93654351219610.036774481814207761.0243839449701140.00137916243205789302.6251939779987250.74624683329088950.080841036681224350.83895920385062310.02786645384844671-0.079616444891192742.5730408082403740.57867462371521810.11301457032655490.6234021722028520.06184576772306752-0.074550873200549163.0048183601342470.42175353633181060.18679020234677960.48026771941790150.113014570326554901.741490570870140.23632879521234350.18679020234677960.308055636897580.169521855489832301.7414905708701660.13373667231957750.29119978012002370.143616424652610.2397647851795663-0.049313817785184842.6050277950847390.03743665007996550.39555099614294190.00445874933043350.331943525138257801.7414905708700770.05090405409287650.45166311651067690.01283492400563050.4238046387245806-0.077924616828094072.576195320722713Internet 0.60.92681704260651451.20.60350877192982320.60.3017543859649116000000000400010.25000000000000-110330000001.201.20.603508771929823200.603508771929823200net zone 5.9446428571428617.8188972431077682.1107142857142790.21.0553571428571390.100004.8892857142857217.80350877192982377.8342857142857120000020001002202120100103311.0707456140350850.084611528822055610.55555555555555560.24444444444444440.27777777777777780.122222222222222200000000000000001.0707456140350850.084611528822055611.0707456140350850.08461152882205561500Reposition Text100000.084611528822055172.1107142857142790.084611528822055172.1107142857142790.11538847117794493.76.4277010804321726.21.2063025210084033.10.60315126050420140000#ffff00#c0c0c01#dddddd100000000010000006.206.21.20630252100840301.206302521008403003.7035714285714236.4668667466986782.350.73109243697478971.1750.365546218487394800000000000000000000100001033100.365546218487394800002.350.365546218487394800001.175000001.1750.73109243697478970000400010.1944444444444444000000000000-1103300000.05090405409287650.36476408617947490.084121969179019510.44777410588639070.0045478688129980.40754647108400702.1563719905971290.2094500782375440.54085492970303980.143616424652610.535893625797581702.1563719905971290.42431554386464750.62057171140470970.23632879521234350.60006720315436902.1563719905971290.61147389558505950.66192818455614660.48026771941787810.68453104144199702.1563719905970640.81163379091893510.68945955825701670.69989064801103460.707023165415688402.1563719905970641.1244397210723460.70681267395713370.9780277596902350.728414357867950802.1563719905970961.2558446204278480.70584091981312371.1634525008097020.728414357867950802.1563719905970641.3952334272090470.70702316541568841.3488772419291920.7284143578679508-0.060924915643816832.3796519184590161.5152712107004920.68945955825701671.4879457977687810.7070231654156884-0.041463021653560383.2171014132824821.759557475283040.66171334006059731.6611505709857230.7073487428233966-0.058147917519852393.1863449819535111.8464911767521250.63492704929175651.8333626535060210.6731221907512972-2.9620638025875232.674958710831192.0534912581831760.57011953372120592.0055747360263430.638895638679197602.1563719905970962.1369323916869390.51450243334531922.1369323916869390.5358936257975817-0.052084047574819583.1978824414865192.2604430854495670.42180176499812882.2656172258809620.4960967086255985-3.128804493302983.2474025793673362.2760009475265510.36476408617947492.322357132806430.386155278631737303.2506031664656912.2674097112589870.32231207212566472.3499989010669620.342265520720994802.1563719905971292.1931683292998270.23517355703459032.2760009475265510.257808123918162802.1563719905971612.1174549233818830.18867324265591732.2296447622466960.1936345465613755-3.135419194456782.7181858276160951.902589457754780.10895646095424752.0905762064070840.129460969204580902.1563719905971291.7154311060343440.067599987802803261.8587952800077390.065287391847793603.2506031664656911.534301983048660.043896199395531161.6733705388882720.0225050069432687302.1563719905971291.3463543387781130.027161810044495951.4415896124889260.001113814491006302-0.02315223715272332.8092995693356741.1634525008097020.022505006943268731.2561648713694360.00111381449100630203.2506031664656910.93654351219610.029699149129805291.0243839449701140.00111381449100630203.2506031664656910.74624683329088950.06528739184779360.83895920385062310.02250500694326873-0.060597023721669273.1794235284042420.57867462371521810.091270805525598630.6234021722028520.04994677254554948-0.057745664339013253.7137854821801880.42175353633181060.15085216165684330.48026771941790150.0912708055255986302.1563719905970960.23632879521234350.15085216165684330.308055636897580.13690620828839802.1563719905971290.13373667231957750.23517355703459030.143616424652610.1936345465613755-0.037578705504203343.2230611957224640.03743665007996550.31944781933959520.00445874933043350.268078291505540602.1563719905970180.05090405409287650.36476408617947490.01283492400563050.3422655207209948-0.059317447523060913.183597829058512Local Wireless Network 1.26.5504201680672261.20.58487394957983090.60.2924369747899154000000000400010.25000000000000-110330000001.201.20.584873949579830900.584873949579830900wifi zone 6.2892857142857115.8334333733493382.821428571428577-1.2668667466986771.410714285714289-0.633433373349338300004.8785714285714236.4668667466986787.75.22000000001002202120100103312.04414765906362700.55555555555555560.24444444444444440.27777777777777780.122222222222222202.04414765906362702.0441476590636270500Reposition Text1000002.82142857142857702.821428571428577-1.2668667466986778.755.93.551.752.50000#c6d1e3#c0c0c01#dddddd1000000000100000000000000001000010331400010.25000000000000-110330000003.503.550500Dom0 - firewall 8.0392857142857187.61.91.1428571428571420.950.571428571428571000000000400010.1944444444444444000000000000-11033000-1.2000000-1000000001.901.91.14285714285714201.14285714285714200eth0 206.124.146.176/24 206.124.146.178/24 206.124.146.179/24 206.124.146.180/24 8.1928571428571326.4714285714285722.4142857142857240.41.2071428571428620.2000000000400010.1944444444444444000000000000-11033000-1.2001000-1000000002.41428571428572402.4142857142857240.400.400eth2 – 192.168.3.254/24 8.7571428571428564.246428571428572.40.57142857142856941.20.2857142857142847000000000400010.1944444444444444000000000000-11033000-1.2000000-1000000002.402.40.571428571428569400.571428571428569400br0 192.168.1.254/24 8.24.028571428571432.20.41.10.2000000000400010.1944444444444444000000000000-11033000-1.2000000-1000000002.202.20.400.400tap0 8.24.4285714285714312.20.41.10.2000000000400010.1944444444444444000000000000-11033000-1.2000000-1000000002.202.20.400.400eth1 8.878571428571433.5017857142856992.5857142857142910.41.2928571428571450.2000000000400010.1944444444444444000000000000-11033000-1.2001000-1000000002.58571428571429102.5857142857142910.400.400eth3 206.124.146.176/32 3.75.0991296518607446.21.2063025210084033.10.60315126050420140000#4e8ec2#c0c0c01#dddddd100000000010000006.206.21.20630252100840301.206302521008403003.7035714285714215.1382953181272492.350.73109243697478971.1750.365546218487394800000000000000000000100001033100.365546218487394800002.350.365546218487394800001.175000001.1750.73109243697478970000400010.1944444444444444000000000000-1103300000.05090405409287650.36476408617947490.084121969179019510.44777410588639070.0045478688129980.40754647108400702.1563719905971290.2094500782375440.54085492970303980.143616424652610.535893625797581702.1563719905971290.42431554386464750.62057171140470970.23632879521234350.60006720315436902.1563719905971290.61147389558505950.66192818455614660.48026771941787810.68453104144199702.1563719905970640.81163379091893510.68945955825701670.69989064801103460.707023165415688402.1563719905970641.1244397210723460.70681267395713370.9780277596902350.728414357867950802.1563719905970961.2558446204278480.70584091981312371.1634525008097020.728414357867950802.1563719905970641.3952334272090470.70702316541568841.3488772419291920.7284143578679508-0.060924915643816832.3796519184590161.5152712107004920.68945955825701671.4879457977687810.7070231654156884-0.041463021653560383.2171014132824821.759557475283040.66171334006059731.6611505709857230.7073487428233966-0.058147917519852393.1863449819535111.8464911767521250.63492704929175651.8333626535060210.6731221907512972-2.9620638025875232.674958710831192.0534912581831760.57011953372120592.0055747360263430.638895638679197602.1563719905970962.1369323916869390.51450243334531922.1369323916869390.5358936257975817-0.052084047574819583.1978824414865192.2604430854495670.42180176499812882.2656172258809620.4960967086255985-3.128804493302983.2474025793673362.2760009475265510.36476408617947492.322357132806430.386155278631737303.2506031664656912.2674097112589870.32231207212566472.3499989010669620.342265520720994802.1563719905971292.1931683292998270.23517355703459032.2760009475265510.257808123918162802.1563719905971612.1174549233818830.18867324265591732.2296447622466960.1936345465613755-3.135419194456782.7181858276160951.902589457754780.10895646095424752.0905762064070840.129460969204580902.1563719905971291.7154311060343440.067599987802803261.8587952800077390.065287391847793603.2506031664656911.534301983048660.043896199395531161.6733705388882720.0225050069432687302.1563719905971291.3463543387781130.027161810044495951.4415896124889260.001113814491006302-0.02315223715272332.8092995693356741.1634525008097020.022505006943268731.2561648713694360.00111381449100630203.2506031664656910.93654351219610.029699149129805291.0243839449701140.00111381449100630203.2506031664656910.74624683329088950.06528739184779360.83895920385062310.02250500694326873-0.060597023721669273.1794235284042420.57867462371521810.091270805525598630.6234021722028520.04994677254554948-0.057745664339013253.7137854821801880.42175353633181060.15085216165684330.48026771941790150.0912708055255986302.1563719905970960.23632879521234350.15085216165684330.308055636897580.13690620828839802.1563719905971290.13373667231957750.23517355703459030.143616424652610.1936345465613755-0.037578705504203343.2230611957224640.03743665007996550.31944781933959520.00445874933043350.268078291505540602.1563719905970180.05090405409287650.36476408617947490.01283492400563050.3422655207209948-0.059317447523060913.183597829058512Remote VPN Clients 1.25.2218487394957981.20.58487394957983090.60.2924369747899154000000000400010.25000000000000-110330000001.201.20.584873949579830900.584873949579830900vpn zone 5.9392857142857115.1691476590636252.1214285714285790.21.060714285714290.100004.8785714285714215.13829531812724975.22000000001002202120100103311.0915666266506650.069147659063624990.55555555555555560.24444444444444440.27777777777777780.122222222222222201.0915666266506650.069147659063624991.0915666266506650.06914765906362499500Reposition Text100000.069147659063624992.1214285714285790.069147659063624992.1214285714285790.1308523409363758.25.12.20.41.10.2000000000400010.1944444444444444000000000000-11033000-1.2000000-1000000002.202.20.400.400tun+ – 192.168.2.x/24 5.72.8110.50.5000000000000000000008PC0000103310.5-0.28891185438368061.310067056935330.57782370876736110.65503352846766510.288911854383680600.5-0.28891185438368060.5-0.2889118543836806221Reposition Text1400010.1944444444444444000000000000-11033DomU – test 192.168.1.7 0.50.066670823103088970.23507054813174780.13332502046048480.11753527406587390.0666625102302424200000.47087378640776740.081433224755700570.17799352750809110.16286644951140040.088996763754045560.081433224755700210000000000.27993527508090680.21640499712642370.55987055016181260.34243430542142160.27993527508090630.17121715271071080000000000.87308608384861290.33329440062868380.45167378582020220.31060989581103630.22583689291010110.155304947905518200000.63511326860841420.56851599455754170.72977346278317170.42648592619436440.36488673139158580.21324296309718220000000000.71019311715303380.62104252337518750.074107917153962710.40820882525200380.037053958576981360.20410441262600190000000000.81391585760517790.67915309446253970.13915857605178010.32899022801302890.069579288025890060.16449511400651440000000000.70388349514563120.88899414047742690.35922330097087370.19595308712332230.17961165048543680.097976543561661150000000000.8236245954692560.37947882736156370.35275080906148820.36156351791531110.17637540453074410.18078175895765560000000000.55161706537309830.8908794788273610.39126002071383380.2182410423452780.19563001035691690.1091205211726390000000000000000000010000103310.19093851132686120.1335504885993480.38187702265372160.2671009771986960.19093851132686080.1335504885993480000000000.27525633703149220.21675116727554720.46733707122103320.2966757718806220.23366853561051660.14833788594031100000.23366853561051660.1516716531372690.46733707122103330.2900082374867060.23366853561051670.14500411874335300000.23367361511928490.14067886796706480.46732523379467470.28135773593412960.23366261689733740.14067886796706480000#969696010100.7000000010.93977617333385910.45660478674157580.044313307504315750.10570743104091590.022156653752157870.0528537155204579500000.53964401294498370.58143322475569980.53883495145631080.76547231270358340.26941747572815540.382736156351791700000.50970873786407770.68269981400057150.2297734627831720.40007268470244020.1148867313915860.20003634235122010000000000.50.5110.50.500000.5491011510017130.32573289902280120.15969097514258450.14332247557003240.079845487571292230.0716612377850161800000.095527899712408940.034201954397394450.12832615086035150.068403908794788570.064163075430175770.0342019543973942800000.07928802588996790.094462540716612240.15857605177993580.097719869706840240.07928802588996790.048859934853420120000000000.079288025889967540.094462540716612240.15857605177993510.097719869706840240.079288025889967540.048859934853420120000000000.59293367751120750.46620521172648020.021705689994778020.029035036806001010.010852844997389010.014517518403000510.52359877566660000.50970873786407770.68269981400057130.22977346278317210.40007268470244010.11488673139158610.20003634235122010000000006.3758085326865493.5192922140910911.2483829346269020.56141557181781870.62419146731345080.280707785908909300005.7516170653730993.23858442818218273.82000000001002202120100103310.34348368140454140.56141557181781870.55555555555555560.24444444444444440.27777777777777780.122222222222222200000004000000000.34348368140454140.56141557181781870.34348368140454140.5614155718178187500Reposition Text10000000.56141557181781871.2483829346269020.56141557181781878.43.82.5857142857142910.41.2928571428571450.2000000000400010.1944444444444444000000000000-11033000-1.2000000-1000000002.58571428571429102.5857142857142910.400.400eth4 206.124.146.176/32 1101192953400.5100101102103104105106107108shorewall-docs-xml-4.5.21/images/Network2009d.png0000644000175000017500000016700612222401136021311 0ustar teastepteastepPNG  IHDRqRD.ЃsBITO IDATx{ufm\#QCI!UE-RddY*BiH rӐs~|;gs3=缟3~|g9}-V8`X"]hRzHi*A ]=&.cEDDD rqN)""""!L)""""R@)SH)EDDD$Pʔ""""(eJ 2JRDDDDL)""""R@)Sd]vs755 s eJ7ß"](R604P,${}*""""LFO¿nwx9 DDDDbݸ`AÿQ53Rttb@ÿMa(S7WDDDD$ (SwmdV}T5QiVñWDDDD4ۣ ރ v0Uᨗ(Sz3Vý `ÏAv8*%"""b:j:j ;, EDDDĉ߃)EDDD$Pʔ""""(eJ 2JRDDDDL)""""R@)SH)EDDD$Pʔ""""(eJ 2JRDDDDL)""""R@)SHF""1e܋8jC^pXH!, SDmٱC YGK1 EeJRG)_I(SL)"A*4JRD"H eJ &Ð#=K%K eJ7)Eo2ʔ"SIGJ"ʔn(SH6M:2b2ʔ"⣨H,E$D)P_{qvDIG" ʔn(SH4P)YHp6Sz""Q(uweHRDZ U[Z)"S;b/PZ)"vJS1VH4G eJW-v" eJ7)E\{"_WƑ8Í4RDL2Hq ^.`'6p;QWʔn(SDvL;x9SWD2ʔ"Q!EϔrL "qK eJ O󡑖)}e)SH+HRPQ{HPRHP@)SH)ED$hVeoиHBD"@RDDDDL)""""R@)SHph0H,)xe҅ {FwgwiڲehV X)]J>eUED$|g?6^I $"qK}"Rk*)EDĆukgoӢۏj))g.cϿ>_:wٷc綜3yyU\ݮ5hTs~gO?Z˼?qViFHRD%`MÏrs7ni<G ߸~]ɓUW?}ԇY3~oٷig<ڵ?; O􈾗HlS[wZh{5k>c?2ݏ7/..5㙢j-s+T(^Seʔy,^5OO%J>9""[D"BŊ@-j=qXF $Hʔ)c޷c?XYbpo5j%- X`rH(SOT)5ّB&= \^4,+}mV 2JR|W ;kh ?m, /:+]vHJp׶}=4J0 /.JlmCmPj9)ō"ۻLQk""-.JTe{ އW m?7 ZN _ -t(fT-p߳!qH2LKiHH$4TJVu9g TPVp-tS,p0Ta th|~ ,UpZA+r쟡)l]XȂ |H|Q[00ҕGitT9KY`>BGviY ̦`췶{2 Հ)^VeJs;b0Cg<Y m{&\ቒd.+Կ߫ `N)V8  `D鋽6aqX{#qtӕfoZu"p2CY@} j )bJs` ]wMp;{aT2,Y|n=l0Ķ*A>@v×CgOlCg^1V#m_R7&vhJY.X!]5xJ# ޅa}4o E?8 6–?P50@>(2qz1q5WWP@w adyh \flp ̄p+u8K,\P'La X#O7:;Bm0:-8WrP;Y+XIFy}茓 ?qA9#&J|FyNǰ{ư{0qju}y@  ar_#%x`g ?C}7p߸i(5HUÃVT``l8 AG@O;,o$A[[c<3S3v^F؇Lm)6h߃/.R*d"c1`` pk pvc8kI'_4]D$H6ym['$|w~@C +l;$np tl8<>Y< N0{1l퐆YO(SZd10bc'ۆ4`7Ur[}061SzF_SǰDv9MʐAȄ>:h/AC|CSl{ c y(S3q OUe `eku^0=D)\DDOPlp>b4Uu5e<>͔A-:_ƀm:숻j$e;vSmWb0#f̱Y~ЙR=yCUr/vJ?S B""s#$iȰuφb\1k9S0Ph6 ?knpaw6-j$y[[?x B'[`q<3 eJ 8_ `yn3+-aLGh HN04%T`"|ۡ%T1`&aZcbA)DBqG~h\k2ڶ'vgЮ=_,l=EO)"~/UKT E[b?,ePpbL$U$X)Et,.Y~&. Pe8, {jCl=v,uܖԁf N4HQx4鈝e#~6@sۏg`%TP vL~lz~S2aj]Ovmh x-Î` +ʔnJC i ]FuX`{;+&ZDQ҉b)&'Â2o9 U?2nڰN2ݐyV < ]lǠ.Kp%ൄM2.@/P^#c0nr;@UH+aN$k?ckXJ>!%r*ɲ2uxF[wYÿmCzZɊ)SFX?m0v)ðAGX!< 0n).ˡӐ ?`0֔ <{` |l{!*m_~ ƭcU)"͖X6`Sm4l(Hm[NϳPjq M-l>UM-hlq a+CZMk _0h _:\% $8 {-ԅC[>hMlp][^;Bwv8\uoC.4tM|rp-.BkG| I5 5T5|VX _~jq{-~nLjaѸx5ի $pdm6X )cʴy7VJiL+R"] _X ئ@)S|HKd%1_ $p ؂TueLmbgF2ߔq{W?4bdh{߽qn^b6.xc|?Fso10ڲ2*/E"] ʔV &B}Ȇ{n3e}f<<.f+֧R#t('$CSyC h@MȁtB Cԅ B{`v3yGv1 5cR$h<!68} M Vض3s8w0|V 3j8gOYemCHFp5l ! C8 -?P UP ãP a;_p lM?6 <0 ,q/9rU 3CHۧcfHT(xJeJZ+`mN܊x7n8g(S_)=1W&X9:9X IdEPwCD{6{Wx+"_k Ijb`~p5US)]E@$*lɻDO;(Mbe$@(͖ &G(X5m:Q%~ӊy(ޥ(+@swSl@iSY`CJҤdèCђ&(% +PXtHi(srr7h*ʔf7Ҿ*U]͓ Z'$JGy8.B(jC$DR2_^5+O"ȈG\hfǓ]G<JGN/UJp=PbqE픦7-iLT4 dktZMӳvL%xoT4rrrO߿FJ)ŏoZBFJP di&ӏTue0洏)19`,)M}OI(26FXU{Z({[=J>{R4)Oߴ!@)a]<1(飳=c4 1#Nߴ~UD}NtM߉4@i6 :+pnܸ_2/~elR07-R}2{b4D29"v6AS!Ҝ({w ?qS""!^X+iwTEeH;UܾL0%Ñ(EDc-y_9-to_b%%R sKltM˭_iiVӅCC籂kY>DRDS#`pN4GSs99a"ʔT-@iKD,{"Z`ktjE`JO)#Xݼ0^UK/P0)ED"K[Sw_c42e9J/_pitʓ( ˺<PzJ+B.rs~n2y9*F`zǘEE,H9.HY/@7eʰVNN<} F۲. L 7ZXe(EDTKEbBQ5N(SߴƏ_sjo@5dYF :{1V:I?hH{-W>%vJ>eŸ]iRMZcJR +M׬h n_beiJ8`d%$۷ $i#Ü>%vcq> J(PN2L<}t,iEX.͖^O(P ǜg8|/;8 qm\Bct nT(̗\wT,eH D~n\(EG9Gns}N@U.ģ@YZʔoZƂUF04%:S5uXc(ED%(eP2e盖۞t_S |}J-iǚ@ "d +Ma:3L~as! _CRW_+WͿo_4)p6Dd'!WE/pPtb{gXm.s@8}xtk!n )J37SƬ(zU86+@)~Mr^q'BA}vT'Qf:3PM5cqmLqn~@i aD$J'l3 eկ֤o%V,E$ZDUC!Ό )Sƚ{"(VH4読(SIؾi"+9R ".PJQ {-p4))Y*V )PJ(SJ\iR"auo;2H09J%K,J 'eJ *Y (PJYeX7 ;4??3CJ Я3|ʔ"d)ZxSLo`Z(E~5k<~ruס "ʔ"fg|)YFV˖-TbL2n,,,LLL Wt<):j _~9ѯ%\rw_}UϞ=+Wܯ_Ç3f̰X,SNxŲh"G>ٳgڵ˔)Sz9r$9(P)E,#hF;e6m^{5cǎu7pCAA#TRbŶmxnա@)jʔ"i!%ˈ+_q^z@ǎڬ^HFK/ԨQ}͙3؞hѢƍgee]ފApL:"aL)4wDŽSv͛7/^>[t#*W x={:w\n/믿X,_}qq1`X ;75O2HST^>HKK[tu֥;w6Fdv֭W~g׮]ƍҥKdBRHhHLѧ3D2HѲ)(E"KR$6U⇾G2H}}1 eJd)J"L)+G͓"fDbI0abپ}}b^8'tu߿b(m[ ,9R1!eJx,ǎ;wM7ԦM`ǎ7|sJ.>Q!6ҢErUZ5===ҴitD$VlOgϞ; .-[˾e˖Q RTY?QRRR^L%R13SĝtZ 0y8p^zvڽ{wnn]vYʕx cˮ]nJ*vmqu}W/;ꫯzYr~>|1cb:u*X,=zX,|AϞ=k׮]Lի0ȑ#?;׿~X~}&M*U4jԨB2K]vSXXxy?655uĉƵmfZ?^JGr4x 2=%Ojxƌ)*:%U2%%sΉ7~뭷gHTS$ޅlٲ*UYn]vɓVtZݻ?m۶57믿nʕ]oХKG=ziӦ@vv/R|UωM6kvagJqgϞsZ .ZjeZ4i)=%Ojx>E=K֭3no~eʔ1K4)--v+W|Y}s=WFO?Cv:tRRR@-{o7~ǵjժU־}o6))[`Aaa>c#p #FRJŊ۶m Jņ @ʰf 2d?$+ӿ W^oބ?wsp8}r,_rR)E$Le,}߿"V@-F}XGy=,u@ժnv9MX^7^]wwW_M&deޤ$n9ȕQ;-oZ_iX&OvsZǢ>Wٶ _ըcT2[L5Xqel(Sʕ_͵K(Ւ("͢4%K G။_\ܰD͌/tSHDܝxmT󤈸D$¢r!JwСCݻwOIIILLlݺumƦMڶm[\-[7>}z)))ʕkӦMAASicƌSbIOO^>pܹf͚Y,|еbEy9ʏ;us*ˉʔ"yQ:z\J_3?~3gN:iҤ/ryyy{>|Y{;5j… o .>AJ,߸'zkQ^bZaSf̈́ =NEyHlxJ1w(c xJ)e˖5vn۶m۾M6 4h3fx饗z_|1--E}]d PL8pAzZr6l_ty'N|^zg?*fs+2==wxJ SH2bCBٟx}@s(t@nn={RSS/ ^z۷;vHNN...:t諯Zbr[~QQш#ƍ׮];ߟݜ9scǺ-_"QG}"b:& }qNIݻv횜i/8uԒ%Kz= Wܹs:4|ÇO>B byyy-jڴi=c9"QJ"bRK̰;¿A999=z(_ 1M41M4+v˖-۷o` ^.ZȑTc7x8##{Qb@FFF~~o:ע|?"HRD, Y{Ƀv-//oљaz왒q饗Ι3B W^fͶlٲtR!s@ժU5jsN`Ŋ{?n!99ٵaÆuعs)SǏ_bQСk޼j}W*Ut…E6eJ1^wg0Pq=̛7ҽ{;?|W,[UbŊQF x;:9m]b޷'K)i޷NE$E2>KoaO?q0Pr{zG:uj=#XS(cņB <)gSN`VX!6D.6F ]#/W:}HQh /PPə!Pm$eJb1`JҤR,#[i ]Cwغu묬,cMڶm[\-[7>}z)))ʕkӦMAASicƌSbIOO^>pܹf͚Y,|еbEy9ʏ;u?q嗗+WC_|E)OediĈ@i9~3gNzȑ3f 0ȑ#{NJJ5k /зo߽{^zwy5k&Nx~ƅj:hР^z{+V|ɃzyNEGZj5c /pĉ-Z 6믟9sqGΣŘLρeJ%fN1P͛76eժU۶m;zMN81y1cƜ;wLKK۷3< t|Ν{ ~f͚>}ĉV̵(Q{bM6ӧ;Vb! byyy-jڴi=~ugÆ  ^ʔ"4O=ԫj͵X,C qt;A_~2''oLHHذaC˖-&MߤI+h׮]޽n`߾}  9r$55(7xGJ,Q~W Ͽs^\999 D/yꩧZn=fO;幝ZEܝP\}1[< _EeEII1)E:v`ӧ۷jժ:uQ0a„3f :tڴiFU)4Xd%^/9(&E$)EC q]{?#NN׈XlJ1 y."bx(:Խ{֭[״wӧR\6m86f̘:uX,tΝk֬bq4kQ^b3.Ҳe֭[wҤIo$+D)ED~eņ|Zc+gΜ:u#Gf̘1`#G];\fĉڏ?*5eРA/+V<T1ע nb{:o޼iӦNOOoӦwt& t2.6$B5)1P.Ylh޼yvvqVZm۶Gnڴu}>3@wOsܹpnnoذ_|1k֬ӧO8m\g?*VJ:utر~f͚+\+qf T+/-&h={^ven߾};cǎ+5īi{*hĈƍk׮Ut[kGըQcٲeSSS]HlSqO?wڵkrrrffӈO)-**N:dɒ޽{ϟ?߸ϝ;СCÇ?|0pcǎX?0nܸkvݺuݻww0eJ(s)cIbbbڵs\:mUX,˗KC-Zdn:{|M2s7Ɔh9997xcBB† ZlmY{ ]v{}.\.ZȑT7xG)(OGWM6[n4h/>qئ"Qzcƌٽ{;S~O>k #>mzi 5jL~tTD,Y4notzau)ERJJ3<|3g;wnڴi,S3X,,q[nݺu+W~ܹӧO_uU*UJLL+ݻw[,onTҔ)S^{ ~gɓ'{w}x7[jX^{jjy_*Tعs'N][o+/_^XXhlӟTJMnڴɾF vm7xcE5k,))iӦK,;vmUP|Zڳg Z-ѣGyM2eʔ)7[?\lYc+V}cdƍ~r-QUC/±cnjYO| /?iʕGܼyAի7k֬gϖcaaann֭[Ϟ=ZYXX8p\fMzzG}4ug㢪?fq,Lo?\TTU 1\r_R2,nej{ 撨XʲpMsg00 p|yؙ|00߳4i$%%2mP9qĻ;++k};w̙3ܪUM6͞=;**j޽ᣏ>*VR[xun6ڽ}ӦMmVŋeu890[n֯ؔZeĉ'NXPWs$S ,׾ڵk˖-/^<`}=:qqqƍ [vmNNNAAAvv믿~…˗/_~ܹsʚݻw6mZnn;s_駟L_|qѮ_*U p}hlӦMz'xb<`PѥK%e>&i͚5k׮5L[nU%,Xݵk׆ ږw+w_BL)w:Ǐ~a`ȑu%b̛7oٲeSL5j԰avڥ ԩS """‚n;wn*Uڶmiɓ'⋂d|ee9((Pf-֯_3,[Wy欬ԋ/N0(66gݷo߈#4ilжo|A^^^>}Əo4kժe0}ݻkԩ&<%kk'Br {IB]@)j)B{(N2BhRXC3 K,q\#R!T@]#-[4 Çs=Ǐ/Ukk6 ]tQ.Z`0$''L˲f͚<}t#L)@ikQQQ۷_n]bbKەP;vٳg~~+*yyy-!*dJ!ЌSރ6 s?&&&ԩSʐo]^gyҔ@ӦM:o`0!!![nݼysÆ 8iӦv`0⋶;Wϕ֦Mq˗[n믿޿X͛7n\z: :* ,{eM~zJJňGB\R!sg k8^!''~n(3eDT:tV5jԉ'nnݺ;w.66cƌ_dɯ_*ϟ?dȐs+oݺw=bĈ7|̙3 4iRjUM6?Ӟ={Ru_~+W,6TyܹݻoIIIFO>޽Çk֬Yb*W\rb;vlСjZnݪUF+Ξ=ۧO?gϞGݲerkO=TRRRHH7-==}ܹ'N>>##C9* :::333))ɶ['xJ!y饗,X,9r`0xnݺ=#XviR)O-'2ظ͟?۶mzkVH &&fjÆ J5d}ڵ+WL}M9ҲG111c\X;婲`:6m'|:|p֖,YtFmܸqŊnrrr, ʭURɛVZ?~۲e 6-,qׄH)^:S:b0\1Rm,q9\v[n*((޽{GDDڵk{YrѣId'|G[n\\܅ bccǖ-[ZO=.,,l„ ۻwڵkɽzήUV>}и5%  K.-]RPFGUr[޴ 6qsٱc2n&{IBҥKoʕ+GEE7~'sss+Wϟ4i]w]9ذ%jtReȐ!h-[$$$\LNNVFr)S4hwΝ[bŐ!C/W^*(,eҺ7oѣǖ-[233LWNqnȑ{>t#3P%PZȰ9Raf0}z?}tj,쮐w]wU\yof>}ny9n(T<Ǐ/Û,XbS;S~nl4T!D1)f?vu2e pz*99oR2Dzz}~oZM4]/<{)Sx+W|y 4^ GI_uNשS',,LU=z#<z1- KKg&sBɔB?~ҥQQQ={~wݺu ^j`w%s'6;a„իW{ժU{3'O5ԩS8iӒ~&:e&d[Q%K\x$gϞUTٺu崘ׯ 7;fW)efg}VYΞ?w}/>}yJŋ ,Yb}=Z.]RY?$S !֯_999-ҥK&ML&;Sz#G*?~<66cǎ]jp}իW/44o>xk֬dɒni޼yUVׯ`Λ=qĴi?h4FGGmo<&''eZw\T_r>ʮ]Qڱj}z"Ra/ݻ8pI&6mǎ￟?xwzYڱBLL'|CM8aÆW.vҷ8o^z/_~g.]ԤI{Yf@-ύ5j۶9FSy|$%q͚Ѡ?եG`:'A2,;;۶0>>طmf7\x ;w޷oZ:Pbnݺ9,4>(ɜ#2CP~z?h~o4m0ٓy!r|^|n#͘1d ݅z$קK/g*F L IDAT&uswNΰaw[Hzn'+$ɔB'B-Hꤦì_:κu>aٽv.5'|""ؼsXA0KтsÆݝ2](k !J}+y}9v={x5jbNfU۷SuGռPpl>sP-x 8l@z.E i~?J$S !viiDtENя0xLv(&LG-[x Ve4 9!<( dRMȽ>'23,%rcp5"0PK NXs^KiՊ BCINYjE@K9… EfKfMY?XnJ*WiS, B wWIMS'bbHOg:N4g@22&8u'-YQ`~-K͚ԯ/9QJ/Ev[͆rٵ""t!Cvc^9sxAh~}dJ!ד@)\!sDv6l@b"v?AH[DTiqqLȶm4oT޽5G dhޜ5ٸm*Vwvm֌LokzI~>̢E\Nhܷ»d2@95W 4'{ ɔB/&RmY6G0~<̙p<@jWwggnaNet4)KUwKoׯ_hݚ] 3Sx)^{b(.]*K} !JQ~rWR&)\-#) 0O^l^AL)35&M8vt>Vʵuz 6mbYrpAG[vCogHI1?ݻ={h҄W_`f22ݻmzɔB(5$(#}sqqBer ѴlI\'VHOYznRodAWuT}Ȑv>nvm6\pjʿJ澅^WBdNܮINEjf ∋?hт8.\ 6x~-уF3Iظ`O3l~kny"F䫯,;ܔ)L2rx1o]Ym.Q`;*U%mR?̠A<;vD.肌S !JȰe1yy=ѣBem RRՋߦR%Y b2h׎7䦛촼};yyvwo4p9Wmm[gU\魣f˩T*\zuyq֯u6z\od_!$P,UZ;wIY@s^`!w/B #BC2l)D$S !J¥2(-B蝶_Yy@NNJ9qܷdJ!8ʕ+%PbR'Wɔ$S !|J6l)RRO)) 'M``~I&-Zи1ZwHBJՊK߸p0>]pRڷZ5v>|C… oGa0vՁڵW ƏY$S !tGtWe˸|OMc0hڔ;n-rF HK+,Y``jצcGCs"l͚s>Bi>խp&OS2e~ù|| ୷BBxv^>}8yps$8S+*a0믘L<шE EʝWU `&;;۴)F#ϻއUBe](zx۰} 4iu+׮Q6b4޽Ux1><|lϚ5uWap?!CWGm֩C\&yq* ?,ʦM< AAZEEJbbaܸ¦M)(7oC2Bd[bxɩ :w&:Յ 1 ϹiԈzug``(^}c$7׼~^&r?&W~h.T OV,[ݤc}L?O` Zi~[%B2<וj-<~ ^ K,];TZ5:ubs%S.YBd$!!<$W"1*UaCƎe2ԨP/ Os sMjv(&t>gOWp)`i=#˷sz3qߛq0/njQ۶^a:w5R_.H(Lilo&LyǏisī3RzCL2B$P Q,ܾE^)E1)z%Rx;3EsZeJK\ϔB $RQ-R.%%RQQ;­, Xd)*dJ!hR!Ra(@--/i#/ތBO@)F읲] ϑqJ!HBliI2l)bBX3 hK>RMvdR@&(4K,6r{Ö(=M2M-|{N\eL)@)p/@Y1$S $P !AQS@~㤙R(vS%P -p2NíϙPíW$ϏSS@}z =HVj *?O_QRL.<{b<'(rJ!t'ą{y8Sd8$9xqC! u|'=A!@i7TeB$YJ+̜p;gʗՅ{Ra,LU Ъzl.Ҕd?Q@)waVq$OfK]~<ȀAJ;(w;BeIgN,J!w [Zwy2SSo# E_j. 9p՜C$YV8샣5 IƩ<4OIs,oglr; X@)9q.̔7LpNV/}.4/A*(t d,+t&:ߺJ!|w͉ d Z~]?EɕC*_+͕dYJQ B[6j5r_6Z= xx @axB>,s0"%m}»r69B [JRee^|̰Z!>t%0j]A!J!Sy|[ Y0CeY8`u` A #? g$P !|d~X T={]` M5Y>@OTvJk !@i?FgUة< qsŠdJ!tD(+zdJ!" ";>l2(7r*L)ܻ]p-RK~ONHBJ!5\R8!R/(vɰIBJ!DdR$S !BNBN-F2B$P !ʦXaKxތBQ B=jK)@)p#9qQ1dR% B)6l)BxBT(W5J͂\ !aÆ6ְ 4zEL)8%&G¥­:Ӱs,pI2.«HB /z砋]պA.HBx{.B)R!tL2AX[,a|WD+H9Q0{C#8RN@Y {%vBIЏ+)qM7_\َu.Bk)U`dA7 @_5q|uNL ܫ&{# F._ 8XѷñD.r)S:ĵXN%J74@hp *V]?T@2C1\`NSйbc4y>=V$ȥBdJUԆ,8C Nu2v}@u Ժ^S a #^ʆ 0| /l0`9\",.zFbR.>8hOt[>0 pX?|{lȥBxSZ .:[$,ZRl맋m) [+TֲT?8(4Q,Jjbc|&#BV2N)hx h{iҲɰBS+ Avir1pX [ !DH&b2ER!R!D24i-V:"R!JCLy n;=x AUQ`kg| xܭ]pn }aӾ.ߤA@s΄!Uu4ﳋ\0*_z-iR`K eBbm6ڐn{ji)S@'XYMr@8< m+`TO^ \$LS`/|V/;FWm*Ubjz;cB2! /Pq+JM !tN -^ 2K7~SjI k Q Ap'\Q|QVC 4 Ȇ p*Tph#P!MpŸ C ޙ0x>pPN' &-P>v϶IJ/v/qz5{/mX6>-*.rA@y5ںB˔y کO6dR vc16տZ Ov}@u ۠— JZd q#t=lS ZM`rx0 ȅߜ#.CMu^sSAԅ`8O u϶V%W[0Wֻ.-T*.n Bn[ru$dAԀSq0`-P& C:LJ% khSka Skok :\pAV~(*S'۩P -`j{%?}֍v/kU yAv- ]٭(82{ժD b` @{{TSnX`Udո#V5a&]!!~10Ϧn?¡gWV`|@;X+Eq@};e ^J_l|W>6inl-qðWJO'BT2e8GJLyD]褾j;mW7X&f"]!AgP!C<썫Մ?8} v@7j'`} "h%> L3d]يEu .A -oIM.r~zR7'R9Shzw2, @{j줮bga&@0 ހHC'x~#Ī tf't/8H T;YZvZ |ӠB'lMU[9b!E2oEo\ZTwgP@)cB'ϛ&CxFjuQz18שO>h. RzbS+;jW[df7P(h}oƇ4޾U#2uŇӤގ,gÒ&JLKhzs!4?ppBφ :dC̷@c){S.;B7)H><6iAJe\F+eBSں.OW*Mb/P ~H2~rBɁX>Nޥ;>]Ւ&gΜ(I?q<H>Σ0C4DXZ_xL=)Rm-MJDq,*p\  K zwX; 4 0AEGVPVt\ݕM p W0s];]K@9sLdJJH df tHǎ ղ%e3ЈdJ6C Vv߰/a $fama #J|}?I'].?}tUGirM udeE@]nǙw0TG7T+r{m@KY0F)8Vwod&m?z%VСw[MMu%PR`` ?II!"""HHhڔCڷ``: !@4Cf%-Z8oy (Uwi`<<,i^+Xc۳׮ IDAT3gI̝Kt4'r_|0boə3 DD_MS@<>&tR_̈́գP ;%59 ߔUj _40j@tWf<ǧKf( v&%P| <(~x)n`Df[&Ə)EdUhoARw; .<'I0LIjtx@K.vm9kuhb}ԍK[&I>IIǓMdfZj{b+.޼b|[.G'0 vC0o0_$MLYinxQ ,ghBVҤRr5'{4L^15 =]3gش8s0wgر8VصL⫹S:UjӦGҽ޿) AgڏPxIG|lRn?JTҤeB+ 7l7ܙ*U8q <xIZgؽjeH\=x{* zAҤpo-\zp^=ٳ/nS2Çya;yH:%Ab$VJQ~a2ں5YYvVޝ_~)Rbw5oɔBw$MȇBBH:"i |]+n'yNqDvŀW~ԣRԗ\g&K'?vϞ !LY&$厦`9 NYhRܱ94Y^YNbBxɔe ':f wP'BMS(I <.Qݭ %w.3XB!MZr#rF {TU_=]xnTĮx^e'kIt8ȱ*/l #s6u&O4[m›1|8Hh(Cᄅ=pxaKiՊ BCINYje ϒ%%oNp!C*%Yb{k٬,sS֏}{ɔn@V` w~+`5CϢ&C$`']!$M_~'7fr*ԭ˽b4n_8ThߞuHLuE65a8~{R&뻺9QJ/xcM]fCCcG""{)w '`ujBH`4}Pǃ<{EΝכh~Qb$P ";v6l 1] $[ "*:mhY˩{4b2q}4oN͚lX6v[6kFzokzIdr A:< ]%d;Xm){NO΃䞊,VpJQaȆ $;IVhӆ~b"#7jٳ xUfbnIʲ#vMzky&Tg2]&Km Xy#k jkp:# [tEBSpeKz $Qƌa$6n$8޽~a[sˋ1r$_}UdLd2?ŋymVwرTR}sTs2N)D&+ RZp@))/P[E0"hm.-\8<00SmeC/dA' 7fX) @Yq]TJ׮%DGS*ի~7zf,Xj&j3ono?VgqbE  C0j@tWP<.tRcV OZ}Z#`!M!jxAUڳp R' E0 (f:VUBMo@H(h OKq)%@(eE!l,[ P?Ӧ1l{rm4mʎ}79m HK+,Y``jצcGC6tEf(hܼ/^HÏ)+kŝS*#x2T* ?;SG) nho-_`-2A{بM q8 uR':Fz2NڍV p&2)WyY>=@\5pzp>Niw 0.PA8P)@Cu'P>h@xC08}ʕ// [o 7SO7$$LɓϝKd$Lj^ߨT _dIFF/ҷW_hЀ/R2Nim\t}mxs7iZ-D 1XF _7zF#1&^RS1ͥn]1c9 :kWsx|k}-y'?ܹݺXFF#AAmN+2N9vla-f۶ip/s~P.^-mӺ'BsGs3.es@ƨ(~,wQԇ? -G+ X QA."b' *"j[k("GcZA.R9rQP$ B?Y&{&dgwW^l|_8i=w {hTYַm)0-~n?,vxd9|=`=߰WA t"7&>a֭HI/?G-X׏ly(*bp!O?5qnc9{yGS ),d׮6=wɱI2xhV=GPOʐX!2a<V|B 3ڸ J! |D;sIRF;sG 5P̟u>]HK>&h^( ))!'Uw5|ٳGhKڵ;`&ZU+܉|4l֭lĦMԯM7{)Fa;]/7۾7m:ϗ$)SF/#dќ85Y&, ^]`m7{6RpYp <9gp a;`uu;k oYlbOmi~񒋬a{`U`-U%WY41,8ܹ=K\q}]ƚ5 5,!L)/g=u|{k)ػ)Q-ЛUC^ [&64a~a.& ᣊ@8`0샮0lV8 5 2( o ><êŔ2p nͣLĕWҫ׹:4f -f=l[SX|!yyqGՁk[kK?WFZr)Sν6-8vݻ2ZDX3RKl"WspA'X ǡ ٶMֈ&ap9 SMp =жe ,WIjCsXz(ka6$Y>_!NB;ȴFHt8YX[o`\>8atG!.3νys֯gt8yv̬C} 1chܘn8Ѭ1s 覦HO?'7ߤatqߑXiGC9mumBO1UT8_OV$㉏_j|CVcKگc@9ʅഭb#̊ 72"A$'AG\̟\xa>ʔ+ʆ3-f<k`U\&{-Ҿ* Vup Xa04 t DQ~ȼ"ᖐ@J .Gm2 :u:7(f)SFQ8-p>):K3S.2FXpMM|c`(F%K` ',`Mg<4*zjH$W\ck=Lʔ,:Ҥ[V}e֊É%=-ۖp,>{@Ȳ\K^~ oA9,Fx]~4Ρ*"RW)#1:Ql~~M! ;xpof~CZŹ}MlZΜq ^>ͭgg_$gm 6伶\DN(Scr,L&񊵒*AZ.QSuH-ض=0 P0%|a 9rr+%jX\#)Sc*y\|iPU+&OHe]fJ3Eswk{vяHeb#PFwj^m*gRJPtB%ej(}PZ<4X)"XɔjJ-kRPmY^s QIU""D@~B[E v k2꼖{'Hc<>."R\~JeU%%%ۿ=r@HY[UP?NHY5A]ɯ 2;ڿ=wj!vb2@>xzjʜ=5sC.(<ը QeP^9DfTeB""Ey=}n2+kJ*MC5q 2pUDɺ |99^f΃zJRėhΔ v_ SSlmIdLMD)E|ڶJ`͏f?m1[i+y#3P^ݤ@$TJp_2'yuۻ2))9;}GC$VI|ʚ iI-1N"Da=eHj(Xmh w-wn̡ Tij!/VO&kXIaʩ$Pz*J#;%V2ݜzJ_*S*P:cfʚtt5+ݭڔ)#OlR%z2e3[ Ln{z)ftsJTf L+c2/Q՟r]@rsW*Pց?ӏTS9NH""NU27weP J 1W=%4Mm"^X,|egGVw$Q xQ۷/ʔm`NJ' u7MeXS)E|oZRK]A+E$橞R{MfY1)D+FReJ6!!tnKjHjʔ"[{.q̚*."1LR’ZK{JCS HRgVX$vSHxW4ۮxPர^4-cezF<D3cezzpBDJRbJg ء@)"CRj0WyG@)"1ER7BGRD$ĢiP@)"P )S]xpAD"C\ :V SJH'""&ʔ+#&EDDJR"vmE< IDATIPJq6eWn}R%EDDTO)xMeFj/a"htԌX:L)QQ>ʔR5 EDܖ̗#Е&ED$(SJElp.P^!_{)Fa8EDDBNR5*\SfU~ܒH]QDkK q uydbHS(i2RP~""6Tz))ս2$@Y,xv(L)A>{9bDOIzFp!([vN?]x(ðB.I{R9FԌ)?p+ёu( je ʔRQӤCRtbLyNPwu5L`ɑn>/itSUD>e ] 22R45ILBQCY! 2e ^qftwQ/K(""2eF?0Q%U\%MΙJdʔ!4&O"")ZQ2sL6ykD e(LR(i |wȤL]*QWT'"" ʔ"ʪڻ[U"")#_XCPD}qeʈY\["/,""M2ygUGA|X)""E2ؓJR7MDDv(SFD,#FViED$Ņފ!{Xi*%q SJpl _UҤgwȶm{͖]rAZ*82DH3ȑґ3z?o22R<\_HQ2{jT#yJLɪԮj=o۶%"L).IQ ( Qqё rEVHH2JJJL)+D(Eb2D\܃*\JqJ H)%E_ ~s `IYL)Q'rD`?Q'ũ# "R)eJX>b6Pj:|wfۉ "LR"SJ5;RNtJXL)":8[tL]^K T}KƋ@*ED$(SJ䋲@YX^jHQS+.VDD")%N,nj0Q=y.-ӤعRdʔc@nJN(+b$fLSiJLz5?HAj~&ʔHJLY;L[]gPR-u_Ÿm^}DΔe60*XؘIқXoqJ#Pfdkq({hm1D"HLY29[{Qn1{K-Ta(SS3ꥧvl o{'W-/c1)=j(ΝJ76uPU8s>DVTw58|_+1%"u)2G,(&oD05׹ wjה)Y/+һ J'Jg:5 TUV?^"59KDLLdJ7y;9P ] 8{PTUjQ_铻CN̏/џ)-1DU)?OL_>D$(ϔj򖘣XY>P>"5y(_ֶ(&3P3JD*ky;QRj*JWUf7J(E$8љ)=jT dg?̜gȑ- " LJ(̔ny8+k Vo JuJ5(]і)k(=[{ܬ!/@rׯիԯj$BΕF4T^^Nѩɧ|V3A&%%ۿφ RwT7Yk>P((PV øohƤIooF0rrr HMMMMM5 GnٲaW]u_W0233k׮a~#wƌsAԩS͚53 /kn۷o||-[lq:-ͦM֮]xނ|72r7|3_RRn?… |qqq+V5jT _w2J2euFk+kBR$jDq%eH c۶mNO?{{:t(!!K..ˬr\/R6mnO?HHHhҤM7tQ;9sfʔ)[oݺuzz>?{sڵ իa+V6 72uT0rss!C~]v]wuM4 >/~-[6lp0 QF]waK.w߮jg͚o/^ظq'&L^ys .>Xh;i&11G p9w~#^xᅶm&$$j( C4QU eN3gc~U@)ayB*z6T %''_r%EEEf6mZVVVaa8555..ٳޯ9sСC_=zt4iZ`>nݚ?wܞ={x}9rd^^GUsvm>ÇǎۺuK/e˖Xwl2nܸ매t:th\\ܛoy5ٳ'11ݧ׿5xcǎ-]tȐ!9btn_r>A?ӪUΝ[o^ȑ#III׿+Ϝ94&kM6mΜ9ٝ;wy9wݸk/-2w'|rԨQݺuۿ[hbŊKŽL@5%'y@oS598FȔ)Y.B0T۷>ؽ{w6mF}wo޼٬L7z:t(`/;;xaŊ>w8y$мy:9rΜ9ύ>M6wy'NXfΜhѢÇ={N>ݰa۷waͻv*))ӧocժU@^-[>]./^Qy]ln* r?4iҪUN:5f̘đ#Gwy{{s=?h4SRR7n|.ZrwNu^{/_Xp_k׮;vt֭A'O:th=6n]ΔuSgP+PJRӧϢE6o޼{MvٝB.z>]}oشiSVk(=}ϋ3Uz7SSS[jլYA? v}QffYW^yŝ)?,Zӟvڹ{Δ;nTF ӧKKKV\yqsѻ)o w]>%XP0>BȬڰaCII9Fo߾K,9qaiii^ذaCE]O2\.{=;t֭qƫW>tЮ]{`nj ӦM{*=V5z̙s1{7oСCg}fi>W廍?>77wĈ 4?e~O?\8a}ށ*.;Sws֬Y4:t;wܹsqƍ~E];tMa_ݻ{{n 999;q'܍oǸ v*))=z9yϔΧ@)5oYte5iѣXX}}嗁Ν;7k֬# 6.,,\xqUVgϞg}o߾ 647osS7k̬\@rr}^y啶m>gsrr6QF΃]z7:ȁ.\W^[Q. NwwGX VlB9 y\.-dG X/njG9sƜnZtiH + xXy]: @19e4ȂB8@*k{ q&\{ Dp .wA.Xj1 \ќk׮v͵ԲeÇ7h`JgϞ>}:0c s2SN%''4n￿ /y晢'Ov鮻{>~˖t8} O^^^n.QcoN^ZZo;K/}@ǎ/={/Δ_}5|p;I&Dp@D$Tn4h og |n_0I6A+h_P\Xm9ԩS 02d2 0 ˕b.٫W/0VXadҥڵKHHxy/ryy_x,h.H3aW^179rfΜgϞիWWy7#F#Gz]O?4###!!I&7tӁ%Kmڴ7^h۶׭[׾} /;6la ,xʔ""Re_ ipY68uRi*CuI*`nٲٳOKK|mh;vԩS/RsiӺw^ZZOر߹nֽ{/RFF~VJLL;wn-V^}`Æ ^xν{{.0rȶmSN-Z0`@AA1cFlٲ믿>̙3ݻ<ڋ/x-\.9rM7۷ūVw"2H Q(ecp~`m 7@ upà5bHk׻w n߾C7o޵kWIIIϞ=5jdy̙?gΜ_P%K\s  Sr-^xO>rʛo^O|SN1"11qȑeee:p! 99 .p'On߾=pw̙3g>w(}<د_gyCEEE[_+777777;;.\Ol ֬Ys%(pR}`֞ԇ+Afl`p-$2'm!2a^D (++vܹvZ*`III$&&;veeewu)>,,,j68p ao6mԪUVZ}@q#W_οK.@BBpiݼSNa)))^)ED:(`Vtr(f>.wZp{=9|t@gx A̔19s.#F\y'SgϞo4 fLtVVЭ[7{Csηzkƍ77>qğ'Ī.X 9a@ۿ5k@c>.qmOdXED$سgϸq㒓/}qWzϘ1[n?pUճg5k?os\Fz-&LXp᫯:mڴ~zɳf˻?f͚{Zn]XXxWV2Ca5ddd$&&ܹshLRf*B|0bv?O{K8 kwޠu]!Ta+q ޶mo]DD$v۷^z.O>@>}v1.ٳgÆ 6lh۾} .|WMv=\|ųg/cǎwyg5]ɓ'_~yyy'Ol׮]fff^[7I&oVMnE;mepB8 8tOh `b័L tT_ƎK 7w{tTGj /HJJ[~iq r;<%0kn -.}( ?VpgAb=kn q3›0̃ Q}R|w{ޭ̪+&W61Hμ"R)Ka[\34akQʘ Y C>'J IDAT#0q (\_`Ne'0c0 [ؚw *)UC)1\Ȇc0f;gi9.?00;.b{"\)̫,oA&lp["CH nDρ>7zS(ryȑ#_O81SԼR]RfU(Y[84< S(~{瘭jp+C; [>BSD s _YӠ oS pF> .XVoZX0l8 PҬO8?}W~OA9<3Vۅ˚:4+|6bua0h6Ԍep=J/IX^Ra܎k׮aӧO7 8pa&Os7l0 0㓓뮓'O6kb.M6񉉉 p?L0YfM4>|dyk5 #33Z*~^-*>k.JO kgrㇼn[>B-SDs[.ȇ1.6CG0'Xg hP ۡl]P}wLAǓ7a-9TznDk[e%ot7oΞ=k&?wy}XIMMmذMrrrڶm۫WǏ>}z۶mW\Q^-Zy>}4inذa :cƌywz٤I+V|}Q||y7mڴvZiٙRꄚ%EvWwz֟.$p]~eeJtE 4TxepLUi{BSb<'8Oں}R4A}c=`V hooA)dJk^>xgyy!C͛n&;wnvvcǦN:k, ##É|~-Z裏;vl>[.++7n\YY[.[JJLb^˗+.]CW+mvԩ?)))w.))9tСCt֬Y뮻rrrٳf`/~e˖枛6Zf`NBBƍ/:ܹs͚5ڵ3bG'gJ}KPD$/l7'AtfvpY!a=\ ESng!,qf&Os-^`'x @.\ o[jy9z ƌ3jԨe˖]^|[nr=;v?~'x}K.2BG?O>{lvvvnnn0:rȈ#wUWZyn3+ǎ;uK/ԴiӺw^ZZjқ똗ӦM+///,,4MMMOĉf/ӧO{fϞ :ujԨQ\\\=?vFiVU)C^? k~*RDsKD [ g\ 10 ?$\ W:н> nzZb뗝 EEE[n s .wڕcǎnݺ5hɓCѣƍ:"k_~yJJʌ3-Z4f̘J_;vK.ovyyyǎ v ⹟9sE>|p\SK, v;vl۶gRSS۷oqq|{6mڌ=޼y tĉM*@˖-5j76w0>Դiycs(S.5yK3[1|n- y &]s ݃Zm eCW+Z6= e0:l砒MU*},ZhͻwNKKkڴiΝݙp6xGnݺu%%%#{۴iɓ'.\5iҤ̦M'O})--6moP͛7:uO<Ѷm'ʔ1JM:x ,/}@ +N9پtCշ> s7 ">FS}W^yeaaO<1w\%,--mРAz5j4tPԩS03g}vԩ .`@Ϟ=۵ksӦM{ܙ0REky;#)Pʰa~ŋoZj9'3QZZ]tM7_Ǝ0ys'&&nٲt\fN ?xƌݺu{ǚ5%țpe5iѣX}}嗁Ν;{<>>CFF>*w9lذQFf۷o?pk0I&ڵAիs͚53*yj2e̱Jl1RIIُxo lr ""5׼yO>=//ɓڵlذ'Nnݺ{wʔ)o#<?cƌ[o̙I&yyywu׼y233 d~xϞ=6lذaɓe oB|||޽}> nݻw߾}s=1,ݔܩSիW?~E7|svvYꫯwrp /9OvfUsX!6x ӤGy{cM(PDzForsW8dd荖cx )cH%pwjLJJ=$(EDD"槌vf?CP(EDD"2eLa4no߳գ@)1'։n#.eJ389rD`p2vI=0 Rwel[r^"}LB(N99'%%惐 Q:rڪ!+Vܩ{xO*.ٶmq}h1:,$dGj>@GddVS,h/Ã.|۳P! 0LsQxzÇ9:&uLst?m!i\!J6 ރ0.vQ06 8A>iC b7gW qL3zS'Wm=e" û4Qkxh+`)Vyn$np;,%0@\D?|5O&n0;pVA9\y\gx&\kLi6C`֌60:~}-1oC9t`zȣL*(kC<Ԟ00_ V؞*,X ǭ-?ڞ@ 򁊍U}|3m`,u<Y6&7U!} 0: km7Z~L)͔)Zlڛu{=.AAZ,r;<%0b>L1tkP*7'pA|f{j7.uȄ0a$y>4pvc> (k1WHkD$)SD@;|9/?w ß==a kY (}`3r $ZC m`Od[::XX oPB_h^=z!ADD" A)^'0Bu @ >rP77h_/ϰlc)|އpix67%0AADD"5<^"l255#|e =eh} m3 wI)RھE"w ܹWUCZ wG ""ljn֨ER$[$ )E|QT eJ_4[$")PR$;J>eAKjsJRTO)K}D<\xvAtXm;>(2h WP€TAx9$" $jY;0 NSa? WjTY/VTO)2㭅ٰCkΡ;~WBOZaXkR 8m flB=+i< '`2Op/+^b4X\/a>p`50?/_YCĚL)2:!НB2Bx%%%gg?}?9sisb(Hq?BS8 Ci0w2!$p [ጵg sl Np ˭N= 8xZH)/VX0jn`(K  7xUpBhLqQlxL/PAl3ʔ"QK) ;(~*WH=`9 `kS<*{|"pwuQ̫yʚbߞ5@ m&%on!ý\pA6Cl+ at0VZK|h{E+ZA8 Cll. )70k0E{K/J2(r{ZD"2mf~6}{+W[!BOߪng0ֶvx6e)g_i0Sk*\c<ܴhT@ dg?bƤd#G0J(|gmhiۭ6A+>ŶLiNp m.< [R@u|RȂVB]u]Ca0k k;Z-S9 @' HQf \@&`u}ʕgUbҘl3is ^)!0Z: ej(X 9gS1_%1X`m g- mMH5WAp_,?`@Oxpmŗ/\޶HhYmu]a5|J(OZsɟgmEwQA>oly:"ʔf֎2a ʕVV Ն^Up$BcxզxTx󮳡bMG5 II99ϻoAjh 0 ^_,OU jcȒ0 ZC!,!j|ҡ \ }`1`eaA&EFT|Y (஫}U^m`$DՖ5P\˧Rt@c8OpL=믾_势* GlХZPYmGe)*>BLapW*# P~ rvCXO}~!fC:a-d,tkӡ-l":a-\ k!'Z]~]T[84< xU;Q%K 6uRlͺ==P Cm~X8ȃk!U6³ߠކ!Vo 6Bx Na)#֟|n}@鮌4GyQ= *#&PԁV_;#}Lxol_8 m?L4,FA1l}O8 ` ̃]'0]vրYbh }'x -?a׭J"(ET64fI=c9$Z1 XVIޭ?D]cl6@i re ss"py3130|3˹)\䆒*.Ec]_7ܔ2Pfp=u;tSFo-NҺ;~&2#cnhoQpg66`{?-=bnts L=L(Jq%$IpWT8jC|#bJLw׿ zs6qϳݜѸLPRprɭ{K1|>-;YJ{L:0SYũŜ?|b\Q=-ZvzGHVRP~N <3*g%wqUY^PҘ5Xc}v!YL]Q<S y-TΓn>έ<̝<.-8U{[Ws?+H-謰8a,13f g%N`)i1%DZ2]ر︞ 9\۲cP HNn#p7"X p]>6ÚyQޑa=\mldwXj@7rdj1eoƈAa0Nn:9.ˊwQN8E ok8aNGn {3F%Q*Kf1U!L۸#""IbʈAU&ӯøtbpDDD4)#_\e?Z#f?Ck8"""d2bhs~Bmi۸#""IDDDlщK)#"""S)#"""S)#"""S)#"""S)#"""S)#:C =;%oNbʈDu)Ra20_Շн-5Sa{{- 9Wv޷ح$஺:ѵڵcMtz.as-"bO2?؛)؋6匧Š=,bv g:1ih7-ܧc.kSVr'>-%Ӓm-Nҩd#.b)[0mp9_X,N\Ÿ3yW1rFq78b/; Ê sB jIDATǧN>N?CRyf1^-Z2ZOui˳""b'ȑ68*'Z7 Oc)֝{$xxU6ؿtUL*r l{]T9H8WyC6jdcgQ-/Կo/E%T(j1rG2ц#e-0),s8)&.e$Ø,tUźėaڃ2.]#EcςKjlm҇*mQZN_eEED.#sml*3)0Us-󊋖E,迎yi A]sO.OHKC+EKfߢV͢""b8eD{jaSj`#Ռ91fs&݌ɣ,L9ш}$hb0+~Bmi29Ӝ]V3} ,:V3tܾ Ti2{۞ةŖHhGpF48eDDDDt*1eDDDDt*1eDDDDt*1eDDDDt*1eDDDDt*1ezPi>;9TXW7"2Ecxz<nZB6UvncvE{ l]g>/=ɩ gqN){1a}55y6s1Ytզ S2pgDn+{3FI/lsvx;Mnfs 4r{p7~7y[,^f]˦vf]U8eJ0/)ot:9Fp-8`2)/Qj<*u2G)(*jg"ù-5Gop@9Sd1 ʼne5WO}<͏Z$q8\SSguqgz#ww9*~М\Sbؕ aX zƀL׶NM|Dr5? tvUu9NyA]1)(.]NT~T0>4ͮj2{*wes;E{Vr-Or!'"bmd2"""":2"""":2bq t=T ]~DDSF 'Q)ְJ”HGQ{11ωA'1enksCwեvwuk榔2aDD.#1e@}өnjF&0kκ )f2u pfc7[~o{ܺ+n> w3OWݧ+YT"q=ُL௨p2բGD.$1eĀjq˛ :g'<ˊop +8y7_b"K_e7%EN>>TVq*s1g91WFDĎ}t"TYrh/Jʏ=‰G@QbfU.*" JS_ƕbLώt3_1I|+c!Ͽe#y2ǹ_ˋ]U)#vwRD(#@nZ1ʶ>͉4.:u?Le5n >^#"bWRl=5V ѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩĔѩ+;;۫Z6DDDNѬ?ѡ\OL IENDB`shorewall-docs-xml-4.5.21/images/bridge2.vdx0000644000175000017500000611766612222401136020551 0ustar teastepteastep dmz1 teastep Hewlett Packard Company 671351309 671351309 AQAAAIwAAAAAAAAAAAAAAHwAAAChAAAAAAAAAAAAAAAcDAAAvQ4AACBFTUYAAAEAHO8AAAMAAAABA AAADwAAAGwAAAAAAAAAAAUAAAAEAABAAQAA8AAAAAAAAAAAAAAAAAAAAADiBACAqQMAVgBJAFMASQ BPAAAARAByAGEAdwBpAG4AZwAAAAAAAABMAAAAfO4AAAAAAAAAAAAAfAAAAKEAAAAAAAAAAAAAAH0 AAACiAAAAIADMAAAAAAAAAAAAAACAPwAAAAAAAAAAAACAPwAAAAAAAAAA////AAAAAABkAAAAKAAA AIwAAADw7QAAKAAAAH0AAACiAAAAAQAYAAAAAADw7QAAAAAAAAAAAAAAAAAAAAAAAP/////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////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//////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////wD////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////8A/////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////AP//////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////wD///////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////8A/////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////AP////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////wD//////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8A///////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////AP////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////wD////////v7+9BUFAwQEAwQEAwQE AwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEA wQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAwQEAw QEAwQECVn5////////////9teG0wQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQ DAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQD AwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDA wQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAwQDAyQDLX19f///////////// //////////8A////////v7+/DDAwAL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/A L+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL +/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AL+/AI+PMEBA////////////FCAUAKcAAL8AAL8 AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8A AL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AA L8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL 8AAL8AAL8AAL8AAL8ACUgJn5+f////////////////////////AP///////7+/vxBAQAD//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//wD//wD//wD//wD//wD//wD//wD//wD//wD// wD//wC/vzBAQP///////////xQgFADfAAD/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/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/AAxgDJ+fn//////////// ////////////wD///////+/v78QQEAA//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//8 A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8Av78wQED///////////8UIBQA3wAA/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/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAMYAyfn5////////////////////////8A////////v7+/EEBAAP//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//AL+/MEBA/ ///////////FCAUAN8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8ADGAMn5+f////////////////////////A P///////7+/vxBAQAD//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//wD//wC/vzBAQP///////////xQgFADfAAD/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/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAxgDJ+fn////////////////////////wD///////+/v78QQEAA//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//8Av78wQE D///////////8UIBQA3wAA/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/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAMYAyfn5//////////////////////// 8A////////v7+/EEBAAP//AP//AP//AH9/AP//AH9/AP//AH9/AP//AH9/AP//AH9/AP//AH9/AP/ /AH9/AP//AH9/AP//AP//AP//AP//AP//AH9/AP//AH9/AP//AH9/AP//AH9/AP//AH9/AP//AH9/ AP//AH9/AP//AH9/AP//AN/fAP//AP//AL+/MEBA////////////FCAUAN8AAN8AAP8AAH8AAP8AA H8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAP8AAP8AAH8AAP 8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAK8AAP8AAP8 AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AAH8AAP8A AM8AAP8ADGAMn5+f////////////////////////AP///////7+/vxBAQAD//wD//wB/fwD//wAAA AD//wAAAAD//wAAAAD//wAAAAD//wAAAAD//wAAAAD//wAAAAD//wBAQAD//wD//wD//wD//wD//w AAAAD//wAAAAD//wAAAAD//wAAAAD//wAAAAD//wAAAAD//wAAAAD//wAAAAD//wD//wD//wC/vzB AQP///////////xQgFADfAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAA AAD/AAAAAAD/AAAAAAD/AABAAAD/AACfAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/A AAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAD/AABgAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAA D/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAxgDJ+fn////////////////////// //wD///////+/v78QQEAA//8A//8A//8Av78A//8Av78A//8Av78A//8Av78A//8Av78A//8Av78A //8Av78A//8Av78A//8A//8A//8A//8A//8Av78A//8Av78A//8Av78A//8Av78A//8Av78A//8Av 78A//8Av78A//8Av78A//8A7+8A//8A//8Av78wQED///////////8UIBQA3wAA7wAA/wAAvwAA/w AAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAA/wAA/wAAvwA A/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAA1wAA/wAA /wAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/ wAA5wAA/wAMYAyfn5////////////////////////8A////////v7+/EEBAAP//AP//AP//AP//AP //AP//AP//AP//AEBAAP//AEBAAP//AEBAAP//AM/PAP//AP//AP//AP//AP//AP//AP//AP//AP/ /AP//AP//AP//AP//AH9/AP//AH9/AP//AH9/AP//AJ+fAP//AP//AP//AP//AP//AP//AP//AL+/ MEBA////////////FCAUAN8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAH8AAP8AAH8AAP8AAH8AAP8AA H8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAFgAAP8AAEAAAP8AAEAAAP 8AAEAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAEAAAP8AAEA AAP8AAEAAAP8AAEAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8ADGAMn5+f//////////////////// ////AP///////7+/vxBAQAD//wD//wD//wD//wD//wD//wD//wAAAAD//wAAAAD//wAAAAD//wAAA AD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wB/fwD//wAAAAD//wAAAAD//w AAAAD//wD//wD//wD//wD//wD//wD//wD//wC/vzBAQP///////////xQgFADfAAD/AAD/AAD/AAD /AAD/AAD/AABAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AADfAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/ AAD/AAD/AADfAAD/AAAAAAD/AAAAAAD/AAAAAAD/AABAAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAxgD J+fn////////////////////////wD///////+/v78QQEAA//8A//8A//8A//8A//8A//8A//8A// 8Av78A//8Av78A//8Av78A//8A7+8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8 A//8Av78A//8Av78A//8Av78A//8Az88A//8A//8A//8A//8A//8A//8A//8Av78wQED///////// //8UIBQA3wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAZgAAiwAAawAAjwAAawAAjwAAaAAAgwAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAdgAAAAAAAAAAAAAAAAAAAAAAAAA AAAACBQIA7wAA/wAA/wAA/wAA/wAA/wAA/wAMYAyfn5////////////////////////8A//////// v7+/EEBAAP//AP//AP//AP//AP//AP//AKenAF9fAF9fAF9fAGVlAO/vAP//AP//AP//AP//AP//A P//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AKGhAF9fAF9fAF9fAGVlAO/vAP//AP//AP //AP//AP//AP//AP//AP//AL+/MEBA////////////FCAUAN8AAP8AAP8AAP8AAP8AAP8AAR0BAAA AAAAAAAAAAAAAAAAAAAAAAAAAAgcCAO8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A ALgAAAAAAQEBAQEBAwMDAwMDAwMDAgICAAAAB2AHAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAFcAAwQDLi4uBi4GAAgAABAAAAAAAAAACAgICUoJAP8AAP8AAP8AAP8AAP8AAP8ADG AMn5+f////////////////////////AP///////7+/vxBAQAD//wD//wD//wD//wD//wD//wMHBxw gICEnJyEnJxUYGAokJAD39wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD/ /wD//wABASEnJyEnJyEnJxUYGAokJAD39wD//wD//wD//wD//wD//wD//wD//wC/vzBAQP/////// ////xQgFADfAAD/AAD/AAD/AAD/AAD/AAMdAw8PDyMjIwBYAAAIAAAgAAAAAAAAAAsMCwZkBgD/AA D/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AADDAAQFBHFxcQ09DQBgAAAjAAAkAAAAAAAAAAk SCQDfAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AABjAC4vLmBgYASTBAC/AAAiAAAA AAAAAAsNCwo6CgD/AAD/AAD/AAD/AAD/AAD/AAxgDJ+fn////////////////////////wD////// /+/v78QQEAA//8A//8A//8A//8A//8A//8BBAR8fHzAwMC4uLhgYGA1ODgOPz8A//8A//8A//8A// 8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8AAACTk5PAwMC1tbVgYGAzNjYOR0cA//8 A//8A//8A//8A//8A//8A//8Av78wQED///////////8UIBQA3wAA/wAA/wAA/wAA/wAA/wADIwMs LHIxMTEAagAAbQAADgAAAAAAAAALDgsHWwcA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA0QAICAgYHRgDEAMANQAAEQAABQAAAAADAwMKFAoA3wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAAwwAGDAYAAAAAAAAAAAAAAAAAAgABBwETGRMKOwoA/wAA/wAA/wAA/wAA/wAA/wA MYAyfn5////////////////////////8A////////v7+/EEBAAP//AP//AP//AP//AP//AP//AQQE fHx8wMDAwMDAYGBgTU1NAAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//A P//AP//AAAAk5OTwMDAwMDAYGBgQ0NDBxsbAP//AP//AP//AP//AP//AP//AP//AL+/MEBA////// //////FCAUAN8AAP8AAP8AAP8AAP8AAP8AAMMABAYEAAAAAAAAAAAAAAAAAAAABAQEChQKBVwFAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8ABE8EAgMCGBgYGBgYGBgYGBgYBQUFBgkG BQ4FAOcAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAD0ALCwshYWFkJCQl5eXo qKiAAAAAREBAL8AAP8AAP8AAP8AAP8AAP8AAP8ADGAMn5+f////////////////////////AP//// ///7+/vxBAQAD//wD//wD//wD//wD//wD//wEEBG5ubpCQkJCQkFFRUU1NTQAAAAD//wD//wD//wD //wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAJCQkJCQkJCQkFFRUUNDQwcbGwD/ /wD//wD//wD//wD//wD//wD//wC/vzBAQP///////////xQgFADfAAD/AAD/AAD/AAD/AAD/AAD/A AMjA1paWq2trcDAwNPT08zMzAYGBgAwAADnAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AACPAAkNCf+Wlv+Wlv+WlvebmyAjIAACAADXAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAD/AAA/AD4+Pv+trf+trf+treeengAAAAMPAwD/AAD/AAD/AAD/AAD/AAD/AAD/ AAxgDJ+fn////////////////////////wD///////+/v78QQEAA//8A//8A//8A//8A//8A//8BA gIQEBAWFhYWFhYCAgJNTU0AAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A// 8A//8A//8AAAAPDw8WFhYVFRUJCQlDQ0MHGxsA//8A//8A//8A//8A//8A//8A//8Av78wQED//// ///////8UIBQA3wAA/wAA/wAA/wAA/wAA/wAA/wADIwNaWlr/ubn/ubn/oaG5ubkHBwcDIgMA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAjwAJDQn/xcX/xcX/ubn3m5slKCUAA AAA0QAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAPwA+Pj7/3Nz/xcX/ra 3nnp4AAAABAwEA/wAA/wAA/wAA/wAA/wAA/wAA/wAMYAyfn5////////////////////////8A/// /////v7+/EEBAAP//AP//AP//AP//AP//AP//AQICAwMDAAAAAAAAAAAATU1NAAAAAP//AP//AP// AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAAABAQEAAAAAAAABgYGQ0NDBxsbA P//AP//AP//AP//AP//AP//AP//AL+/MEBA////////////FCAUAN8AAP8AAP8AAP8AAP8AAP8AAP 8AAyMDWlpa/9zc/8XF/6GhpqamCQkJAw8DAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAI8ACQ0J797e78zM77u76aSkJSglAAAAAMMAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AADMAJSUlfX19fX19fX19fX19AAAAAQMBAP8AAP8AAP8AAP8AAP8AAP8AA P8ADGAMn5+f//// ////////////////////AP///////7+/vxBAQAD//wD//wD//wD//wD//wD//wECAgMDAwAAAAAAA AAAAE1NTQAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAA AAAAAAAAAAAAYGBkNDQwcbGwD//wD//wD//wD//wD//wD//wD//wC/vzBAQP///////////xQgFAD fAAD/AAD/AAD/AAD/AAD/AAD/AAMdAw4PDiUoJSUnJSUmJRweHAoKCgMPAwD/AAD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AACqAAABAAAAAAAAAAAAAAAAAAICAgEBAQDDAAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AADSAAIGAgAAAAAAAAAAAAAAAAAAAAEDAQ D/AAD/AAD/AAD/AAD/AAD/AAD/AAxgDJ+fn////////////////////////wD///////+/v78QQEA A//8A//8A//8A//8A//8A//8BAgICAgIAAAAAAAAAAABNTU0AAAAA//8A//8A//8A//8A//8A//8A //8A//8A//8A//8A//8A//8A//8A//8A//8AAAACAgIAAAAAAAAEBARDQ0MHGxsA//8A//8A//8A/ /8A//8A//8A//8Av78wQED///////////8UIBQA3wAA/wAA/wAA/wAA/wAA/wAA/wAA0gADCQMAAA AAAAAAAAAAAAAAAAADDQMA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA EgwQAAAAAAAAAAAAAAAAAAAABAwEA2QAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA /wAA/wAA/wAA4AAAjwAAJAAAawAAjwAAjwAAtwAA/wAA/wAA/wAA/wAA/wAA/wAA/wAMYAyfn5/// /////////////////////8A////////v7+/EEBAAP//AP//AP//AP//AP//AP//AQICAWoBADAAAA AAAAAATU1NAAAAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AAA AAHgAABgAAAAABQUFQ0NDBxsbAP//AP//AP//AP//AP//AP//AP//AL+/MEBA////////////FCAU AN8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAOAAAI8AAFkAADYAAI8AAI8AAOAAAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAH8AAH8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAEAAAL8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8ADGAMn5+f////////////////////////AP///////7+/vxBA QAD//wD//wD//wD//wD//wD//wECAgErAQAAAAAAAAAAAE1NTQAAAAD//wD//wD//wD//wD//wD// wD//wD//wD//wD//wD//wD//wD//wD//wD//wAAAAEpAQAAAAAAAAYGBkNDQwcbGwD//wD//wD//w D//wD//wD//wD//wC/vzBAQP///////////xQgFADfAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD /AACfAABgAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/ AAD/AAD/AAB/AAB/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AABAAAC/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAxgDJ+fn/ ///////////////////////wD///////+/v78QQEAA//8A//8A//8A//8A//8A//8BAgIBagEAMAA AAAAAAABNTU0AAAAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A AAAAeAAAMAAAAAAEBARDQ0MHGxsA//8A//8A//8A//8A//8A//8A//8Av78wQED///////////8UI BQA3wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAnwAAYAAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAfwAAfwAA/wAA/wAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAQAAAvwAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAMYAyfn5////////////////////////8A////////v7+/E EBAAP//AP//AP//AP//AP//AP//AQMDBgYGBQUFBQUFBwcHVFdXAAAAAP//AP//AP//AP//AP//AP //AP//AP//AP//AP//AP//AP//AP//AP//AP//AAEBBwcHBQUFBgYGCQoKSUpKBxsbAP//AP//AP/ /AP//AP//AP//AP//AL+/MEBA////////////FCAUAN8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAJ8AAGAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAH8AAH8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAEAAAL8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8ADGAMn5+ f////////////////////////AP///////7+/vxBAQAD//wD//wD//wD//wD//wD//wCTkwMGBkBA QEBAQEBAQC40NAAAAAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD// wCTkwMGBkBAQEBAQEBAQCkqKgcWFgD//wD//wD//wD//wD//wD//wD//wC/vzBAQP///////////x QgFADfAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AACfAABgAAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAB/AAB/AAD/AAD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AABAAAC/AAD/AAD/A AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAxgDJ+fn////////////////////////wD///////+/v7 8QQEAA//8A//8A//8A//8A//8A//8A//8AqKgEEBAEDQ0EBwcEEBAHNTUA//8A//8A//8A//8A//8 A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8AqKgEEBAEEBAEDQ0EBwcFODgA//8A//8A //8A//8A//8A//8A//8Av78wQED///////////8UIBQA3wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAAnwAAYAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAAfwAAfwAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAAQAAAvwAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAMYAyf n5////////////////////////8A////////v7+/EEBAAP//AP//AP//AP//AP//AP//AP//AP//A P//AL+/AEBAAP// AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//A P//AL+/AEBAAP//AP//AP//AP//AP//AP//AP//AP//AL+/MEBA////////////FCAUAN8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAJ8AAGAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAH8AAH8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAEAAAL8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8ADGAMn5+f////////////////////////AP///////7+/vxBAQAD//wD//w D//wD//wD//wD//wD//wD//wD//wC/vwBAQAD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD //wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wC/vwBAQAD//wD//wD//wD//wD//wD//wD/ /wD//wC/vzBAQP///////////xQgFADfAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AACfAABgA AD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA B/AAB/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AABAAAC/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAxgDJ+fn/////////// /////////////wD///////+/v78QQEAA//8A//8A//8A//8A//8A//8A//8A//8A//8Av78AQEAA/ /8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A// 8A//8Av78AQEAA//8A//8A//8A//8A//8A//8A//8A//8Av78wQED///////////8UIBQA3wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAnwAAYAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAfwAAfwAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAQAAAvwAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAA/wAMYAyfn5////////////////////////8A////////v7+/EEBAAP//AP/ /AP//AP//AP//AP//AP//AP//AP//AL+/AEBAAP//AP//AO/vAGVlAF9fAF9fAF9fAF9fAF9fAF9f AF9fAF9fAF9fAF9fAF9fAGVlAO/vAP//AP//AP//AP//AL+/AEBAAP//AP//AP//AP//AP//AP//A P//AP//AL+/MEBA////////////FCAUAN8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAJ8AAG AAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAOcAAL8AAL8AAL8AAL8AAL8AAL8AAL8AAL8 AAF8AAF8AAL8AAL8AAL8AAL8AAL8AAL8AAL8AAPcAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAEAAAL8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8ADGAMn5+f///////// ///////////////AP///////7+/vxBAQAD//wD//wD//wD//wD//wD//wD//wD//wD//wC/vwBAQA D//wD//wQwMA8RERQXFxQXFxQXFxQXFxIVFRIVFRIVFRQXFxQXFxQXFw8RERIUFAYgIAD39wD//wD //wD//wC/vwBAQAD//wD//wD//wD//wD//wD//wD//wD//wC/vzBAQP///////////xQgFADfAAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AACfAABgAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/A ADRAAIIAgQIBAYMBgYLBgYKBgYLBgYMBgYLBgYLBgYJBgYIBgYLBgYLBgYMBgYLBgYLBgUJBQYKBg QXBADvAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AABAAAC/AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAD/AAD/AAxgDJ+fn////////////////////////wD///////+/v78QQEAA//8A //8A//8A//8A//8A//8A//8A//8A//8Av78AQEAA//8A//8DIyMeICASExMSExMSExMSExMSExMSE xMSExMSExMSExMSExMAAAATFBQkLS0NR0cA9/cA//8A//8Av78AQEAA//8A//8A//8A//8A//8A// 8A//8A//8Av78wQED///////////8UIBQA3wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAnwA AYAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAjwAUFxYGBwcMDg4MDg4AAAAMDg4MDg4GBwcH BwcMDg4MDg4AAAAMDg4MDg4GBwcTFRUAAAAAAAAlKicMPgwA9wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAAQAAAvwAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAMYAyfn5//////// ////////////////8A////////v7+/EEBAAP//AP//AP//AP//AP//AP//AP//AP//AP//AN/fABA QAAAAAAAAAwUFODg4kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQWlpaNTw8HR0dAAAA AAAAAAAAAAAAAHBwAP//AP//AP//AP//AP//AP//AP//AP//AL+/MEBA////////////FCAUAN8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAJ8AAGAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAI8AExcUPUBBSU1OSU1OMTM0Q0dHSU1OPUBBPUBBQ0dHQ0dHMTM0SU1OSU1ONzo6PUBBMTM0MTM 0IykkYWFhEkQSAPcAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAEAAAL8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8ADGAMn5+f////////////////////////AP///////7+/vxBAQAD// wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wD//wODgwoSEiw3Ny05OS05OS05OS05OS 05OS02Ni05OS05OS05OS05OS05OWiVlR0tLQC/vwD//wD//wD//wD//wD//wD//wD//wD//wD//wD //wD//wD//wC/vzBAQP///////////xQgFADfAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AACv AAAYAABAAABAAABAAABAAABAAABAAABAAABAAABAAAAkAAkLCcDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBIZEoeHhzM2MwAoAABAAABAAABAAABAAABAAA BAAABAAABAAABAAAAQAADPAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAxgDJ+fn////// //////////////////wD///////+/v78QQEAA//8A//8A//8A//8A//8A//8A//8A//8A//8A//8A //8A//8A//8A//8FtrYvQ0Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3MPHBwAv 78A//8A//8A//8A //8A//8A//8A//8A//8A//8A//8A//8A//8Av78wQED///////////8UIBQA3wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAAxwAAvwAAvwAAvwAAvwAAvwAAvwAAvwAAvwAAvwAAdAACAwIoNC goNCgoNCgoNCgoNCgoNCgoNCgoNCgoNCgoNCgoNCgoNCgoNCgoNCgoNCgoNCgoNCgEBwSMjIwzPDM AdwAAvwAAvwAAvwAAvwAAvwAAvwAAvwAAvwAAvwAAzwAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA /wAA/wAA/wAMYAyfn5////////////////////////8A////////v7+/EEBAAP//AP//AP//AP//A P//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AL+/AH9/AH9/AH9/AH9/AG9vABAQAH9/AE dHAH9/AD8/AH9/AD8/AI+PAH9/AP//AH9/AP//AH9/AP//AL+/AP//AP//AP//AP//AP//AP//AL+ /MEBA////////////FCAUAN8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAH8AAP8AAH8AAP8AAH8A AP8AAH8AAP8AAH8AAP8AAH8AAP8AAO8AC2ILS1dLrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysu7u7ks6SMz8zAJ8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8ADGAMn5+f/////////////////// /////AP///////7+/vxBAQAD//wD//wAAAAD//wAAAAD//wAAAAD//wAAAAD//wAAAAD//wAAAAD/ /wCfnwD//wD//wD//wD//wD//wDf3wAgIAD//wD//wAAAAD//wAAAAD//wAAAAD//wAAAAD//wAAA AD//wAAAAD//wD//wD//wD//wD//wD//wD//wC/vzBAQP///////////xQgFADfAAD/AAD/AAD/AA D/AAD/AAD/AAD/AAC/AAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAAAAAD/AAD/AA5 +DkxYTHNzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzcxko GQCfAAD/AAD/AAD/AAD/AABAAAD/AABAAAD/AABAAAD/AABAAAD/AABAAAD/AABAAAD/AABAAAD/A ABYAAD/AAD/AAxgDJ+fn////////////////////////wD///////+/v78QQEAA//8Az88A//8AQE AA//8AQEAA//8AQEAA//8AQEAA//8AQEAA//8AQEAA//8A//8A//8A//8A//8A//8A398AICAA//8 Ax8cA//8Av78A//8Av78A//8Av78A//8Av78A//8Av78A//8A398A//8A//8A//8A//8A//8A//8A v78wQED///////////8UIBQA3wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAvwAA/wAAvwAA/wAAv wAA/wAAvwAA/wAAvwAA/wAAvwAA/wAA9wAA/wAA/wAAnwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAAA AAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAA7wAA/wAA/wAA/wAAfwAA/wAAAAAA/wAAAAA A/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAAAAAA/wAA/wAA/wAMYAyfn5////////////////// //////8A////////v7+/EEBAAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP//A P//AP//AP//AP//AP//AP//AP//AN/fACAgAP//AP//AP//AP//AP//AP//AP//AP//AP//AP//AP //AP//AP//AP//AP//AP//AP//AP//AP//AP//AL+/MEBA////////////FCAUAN8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAL8AAP8AAL8AAP8AAL8AAP8AAL8AAP8AAL8AAP8AAL8AAP8AAL8AAP 8AAMcAAP8AAP8ADGAMn5+f////////////////////////AP///////8fHxwcQEBBAQBBAQBBAQBB AQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQA44OAIICBBA QBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQBBAQ AwwMDpISP///////////xcgFw44DhBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEB BAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEAA AABBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBA EBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEBBAEAgYCJ+fn//////////////// ////////wD////////////Hx8e/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7 +/v7+/v7+/v7+/v7+/v7+/v7+/v7+np6cYGBi/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+ /v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7/n5+f////////////X19e/v7+/v7+/v7+/ v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v 7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v78AAAC/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/39/f///////////////////////8A//////////////////////////// ////////////////////////////////////////////////////////////////////39/fICAg/ ///////////////////////////////////////////////////////////////////QEBA////QE BA////QEBA////QEBA////QEBA////QEBA////QEBA////QEBA////QEBA////QEBA////QEBA/// /QEBA////QEBA//////////////////////////////////////////////////////////////// AAAA///////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////AP///////////////////////////////////////////////////////////////// //////////////////////////////9/f3yAgIP////////////////////////////////////// /////////////////////////////////wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///wAAA P///wAAAP///wAA AP///wAAAP///wAAAP///wAAAP///wAAAP///wAAAP/////////////////////////////////// ////////////////////////wAAAP//////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////wD///////////////////////////////////////// ///////////////////////////////////////////////////////f398gICD////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////8dHR0cHBza2tr//////////////////////////////////////// ///////////////////////////////////////////////////////////////8AAAD///////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////8A// ///////////////////////////////////////////////////////////////////////////// /////////////////39/fICAg//////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AAAAxsfIMzM01 9fX////////////////////////////////////////////////////////////////////////// //////////////////////////AAAA/////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////AP/////////////////////////////////////// ////////////////////////////////////////////////////////9/f3yAgIP//////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////wAAAOTk5rOzszIzNNbW1v////////////////////////////// /////////////////////////////////////////////////////////////////wAAAP/////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////wD ///////////////////////////////////////////////////////////////////////////// ///////////////////f398gICD////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////8AAADh4uTJys 6zs7MyMzTV1dX//////////////////////////////////////////////////////////////// ///////////////////////////8AAAD///////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////8A////////////////////////////////////// //////////////////////////////////////////////////////////39/fICAg/////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////AAAA4+Plzc3NycrOs7OzMjI02tra///////////////////// ///////////////////////////////////////////////////////////////////AAAA////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// AP/////////////////////////////////////////////////////////////////////////// ////////////////////9/f3xAQEH9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f3 9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/fwAAAOLj5cn KzsnKzsnKzl9gZlRUVH9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/ f39/f39/f39/f39/f39/f39/f39/fwAAAP/////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////wD//////////////////////////////////// ///////////////////////////////////////////////////////////////+Pj49/f39/f39/ f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f 39/f39/f39/f39/f39/f39/f39/f38AAADFxsjNzc3Nzc3Nzc1lZmZYWFh/f39/f39/f39/f39/f3 9/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f3+fn5///// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /8A////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////QEBA////QEBA////QEBA////RkZGAgICDw8P KSkpycrOycrOY2Rmb29vWFhY////QEBA////QEBA////QEBA////QEBA////QEBA////QEBA////Q EBA////QEBA//// QEBA////QEBA////QEBA////QEBA////z8/P///////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////AP///////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////wAAAP/// wAAAP///////+jo6BISEk1NTScnKDs7O83NzWVmZm9vb////wAAAP///wAAAP///xwcHP///wAAAP ///wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///wAAAP///// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////wD////////// ///////////////////////////////////////////////////////////////////////////// ////////9/f3////9/f3////9/f3////9/f3////9/f3////9/f3/////f39///////////////// ////////////////////////////////////////////////////////v7+8UFBRra2snJyc7Oztk ZWZvb2/////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////8A//////////////////////////////////////////////// ////////////////////////////////////////////YGBg////AAAA////AAAA////AAAA////A AAA////AAAA////AAAA////////////////////////////////////////////////////////// //////////////////////PDw8DQ0Na2trJycoHR0dcHBw/////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////AP//////// ///////////////////////////////////////////////////////////////////////////// //////////7+/v////7+/v////7+/v////7+/v////7+/v////7+/v////+/v7/////////////// /////////////////////////////////////////////39/f////39/f////zw8PLOzsxgYGGxsb BsbGxUVFf//////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////wD////////////////////////////////////////////// /////9/f3////9/f3////9/f3////9/f3////9/f3////9/f3////9/f3////9/f3////9/f3//// 9/f3////9/f3////9/f3////9/f3////9/f3////9/f3////9/f3////9/f3/////f39///////// ///8gICD///8AAAD///8AAABAQEC/v7/v7+8UFBQAAAAGBgb///////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////8A/////// /////////////////////////////////////////YGBg////AAAA////AAAA////AAAA////AAAA ////AAAA////AAAA////AAAA////AAAA////AAAA////AAAA////AAAA////AAAA////AAAA////A AAA////AAAA////AAAA////AAAA////////////////////v7+/////v7+/////Pj4+v7+/////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////AP//////////////////////////////////////////// ///////7+/v////7+/v////7+/v////7+/v////7+/v////7+/v////7+/v////7+/v////7+/v// //7+/v////7+/v////7+/v////7+/v////7+/v////7+/v////7+/v////7+/v////+/v7////6+v rwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAwMEP///////////////////////////////////////wD///// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////+fn58MDGAAAP8AAP8AAP8AAP8AAP8AAEAAAL8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAD////////////////////// /////////////////8A////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////n5+fDAxgAAD/AAD/ AAD/AAD/AAD/AABAAAC/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/AAAA////////////////////////////////////////AP////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////5+fnwwMYAAA/wAA/wAA/wAA/wAA/wAAQAAAvwAA/wAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAvwAA/wAAvwAA/wAAvwAA /wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAAvwAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/ wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAP//////////////////// ///////////////////wD//////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////+fn58MDGAAAP8AA P8AAP8AAP8AAP8AAEAAAL8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAJ8AAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8 AACAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAAD///////////////////////////////////////8A///////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////n5+fDAxgAAD/AAD/AAD/AAD/AAD/AABAAAC/AAD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAB/AAD/AAB/AAD/AAB/A AD/AAB/AAD/AAB/AAD/AAB/AAD/AAB/AAD/AAB/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA D/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA/////////////////// /////////////////////AP////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////5+fnwwMYAAA/w AA/wAA/wAA/wAA/wAAQAAAvwAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAA/wAA/wAA/wAA/wAAfwAA/wAAfwAA/wAAfwAA/wAAfwAA/wAAfwAA/wAAfwAA/wAAfwAA /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/////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////+fn58MDGAAAP8AAP8AAP8AAP8AAP8AAEAAAL8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAN8AAP8AAAAAAP8AAA AAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAGAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAD///////////////// //////////////////////8A///////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////n5+fDAxgAAD /AAD/AAD/AAD/AAD/AABAAAC/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAB/AAD/AAB/AAD/AAB/AAD/AAB/AAD/AAB/AAD/AAB/AAD/AAB/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/AAAA////////////////////////////////////////AP///////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////5+fnwwMYAAA/wAA/wQENwMDDwMDDwMDBgMDCAMDDgMDDwMDDw MDDwMDGAAA7wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A5wAAvwAAvwAAvwAAzwAA/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////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////+fn58MDGAAAP8AAJsHBwpnZ15 RURtRURtRURtRURtRURtWVitDQ0McHCUPDzYAAO8AAP8AAP8AAP8ACFgADigACmgAAKcAAOcAAP8A AP8AAP8AAKgAAAAAAAAAAAAAAAAoKCgqKioqKioeHh4AAAAAAAAAAAABAQgAAMoAAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAAD///////////////////////////////////////8A/////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////n5+fDAxgAAD/AADRAgIEb29sS5snS0t3S0t3T48vTFRtT5cxT09PGBgifX19Dw 8rAAC7AAD/AAD/AACvACcwAFhYAAAAAAAAAA4oAApoAACnAABaZWVnoKCglZWVtsy2pNqksNqwq9q rrNasw8PDo6Ojm5ubUlJXDg4mAADfAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/ AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA///////////////////////////// ///////////AP//////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////5+fnwwMYAAA/wAA/wYGbCMj LHNzc3Nzc3Nzc3Nzc3Nzc3Nzc3Nzc21tfYuLnk1NTQAAAAAAAAAMIAAQQAAAAAC3twAHEAAAnwAAf wAPUAAHOAAAAAUFBUFBQYWFhS6mLgvVCwrcCgzUDAflB0iASImJiX9/fxsbIU9PTwoKPgAA/wAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wA A/wAA/wAAAP///////////////////////////////////////wD///////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////+fn58MDGAAAP8AAP8AAP8JCZ5GRljm5ubm5ubm5ubm5ubm5ubm5ubm5ubDw99 FRVMAAH8AAL8AAH8AEEAAAAAAHigAJCgABI8AAP8AAP8AAP8AALUFBQgsLCxBQUF9hX2Xt5eXtped tJ2Xt5d2fnY6Ojo6Ojo7O0FjY24MDRcAAP8AAP8AAN8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAD/////////////////////////// ////////////8A/////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////n5+fDAxgAAD/AAD/AAD/A AD/CQmeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACvAAD/AAD/AAD/AAD/AAC/AAB/AAqfAA D/AAD/AAD/AAD/AADPGBgtKys7Kys7Kys7Kys7Kys7Kys7Kys7Kys7Kys7Kys7HBwsCAsVAAx/AAD /AAUQAAWXAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/ AAD/AAD/AAAA////////////////////////////////////////AP/////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////5+fnwwMYAAA/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/wAA3wAAvwAAvwAAvwAAv wAAvwAAvwAAvwAAvwAAvwAAvwAAvwAAvAAECAAEeAAiMAAVKAAA5wAA/wAA/wAA/wAA/wAA/wAA/w AA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAP///////////////////////// //////////////wD///////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////+fn58MDGAAAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AC3gA AAAAe38AGyAAEVgAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAAD///////////////////////////////////////8A////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////n5+fDAxgAAD/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/AAD3AA0gAJeXAAggAAQIAAC3AAD/AAD/AAD/AAD/AAD /AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA//////////////////////// ////////////////AP/////////////////////////////////////////////////////////// /////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////5+fnwwMYAAA/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/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAvwAGCAAEfwAJ jwAJIAAA9wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAA P///////////////////////////////////////wD/////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////+fn58MDGAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8ABH8AAOcAAP8ADVAACHgAAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAAD///////////////////////////////////// //8A///////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////n5+fDAxgAAD/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/AAD/AAD/A AD/AADvAAQoAADPAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AA AA////////////////////////////////////////AP///////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////5+fnwwMYAAA/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/wAA/wAA/wAA/wAA/wAA/wAA/8/Pz93d3eTk5AAA/wAA/wAA/wAA/wAA /wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAAP/////////////////////////////////// ////wD/////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////+fn58MDGAAAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP/l5e Xj4+Ph4eHh4eHf39/e3t7e3t7e3t7f39/g4ODh4eEAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAAD///////////////////////////////////////8A//////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////n5+fDAxgAAD/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/5ubm4+Pj4eHh39/f3d3d3Nzc2tra2dnZ2dnZ2dnZ2tra3Nzc3 d3d3t7e4eHhAAD/AAD/AAD/AAD/AAD/AAD/AAD/AAAA////////////////////////////////// //////AP///////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////5+fnwwMYAAA/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/+Xl5ePj4+Dg4N3 d3dvb29nZ2dfX19XV1dXV1dXV1dXV1dXV1dfX19jY2Nvb293d3eDg4OLi4uXl5QAA/wAA/wAA/wAA /wAAAP///////////////////////////////////////wD////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////+fn58MDGAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8A AP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP/m5ubj4+Pj4+Ph4eHf39/d3d3b29vY2NjW1tbU1NTS0tLQ0NDOzs7Nzc 3b29vW1tbZ2dnc3Nzf39/j4+Pl5eUAAP8AAP8AAP8AAAD//////////////////////////////// ///////8A//////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////// ////////////////////////////////////n5+fDAxgAAD/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/5eXl5ubm5eXl4+Pj4eHh39/f3d3d29v b2dnZ19fX1tbW1NTU5ubm4uLi3t7e2tra1tbW09PT0dHRzs7O5OTkAAD/AAD/AAD/AAAA//////// ////////////////////////////////AP/////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////5+ fnwwMYAAA/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/+Pj4+Dg4Obm5ubm5uTk5OLi4uHh4d/f3wAAANvb2wAAANnZ2QAAAObm5gAAAODg4N7e3t vb29ra2tnZ2ePj4wAA/wAA/wAA/wAAAP///////////////////////////////////////wD//// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////+fn58MDGAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP/j4+Pf39/c3Nzm5ubm5ubm5ubk5OQ5 OTnh4eEAAADf398AAADc3NwAAADb29ttbW3a2trh4eHh4eHf39/j4+MAAP8AAP8AAP8AAAD////// /////////////////////////////////8A////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// n5+fDAxgAAD/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/4ODg3Nzc2dnZ1tbW0tLSz8/PzMzMyMjI5eXl5OTk4+Pj29vb19fX4eHhzs7Oy8v L2dnZ3Nzc39/f4+PjAAD/AAD/AAD/AAAA////////////////////////////////////////AP// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////5+fnwwMYAAA/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/97e3tra2tfX19XV1dLS0 s/Pz83NzcvLy+Li4uHh4d3d3dra2tXV1dLS0s/Pz8zMzN3d3eHh4eTk5AAA/wAA/wAA/wAAAP//// ///////////////////////////////////wD//////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /+fn58MDGAAAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8 AAP8AAP8AAP8AAP8AAP8AAP/d3d3a2trX19fV1dXS0tLR0dHQ0NDj4+Pk5OTg4ODc3NzZ2dnW1tbT 09PS0tLg4ODj4+MAAP8AAP8AAP8AAP8AAAD///////////////////////////////////////8A/ ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////n5+fDAxgAAD/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/19fX1tbW1dXV1dXV5ubm4+Pj4eHh3t7e29vb2dnZ2NjY4uLi5eXlAAD/AAD/AAD/AAD/AAAA/// /////////////////////////////////////AP////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///5+fnwwMYAAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAA/wAAQAAA/wAAQAAA/wAAQAA A/wAAQAAA/wAAQAAA/wAAQAAA/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/9nZ2dnZ2dra2uXl5eLi4uDg4 N7e3t3d3eXl5ebm5gAA/wAA/wAA/wAA/wAAAP///////////////////////////////////////w D//////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////+fn58MDGAAAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8A AJ8AAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AAAAAAP8AACAAAP8AAP8AAP8AAP8AAP8AAP8AA P8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP8AAP 8AAL8AAP8AAP/h4eHh4eHj4+Pk5OTm5uYAAP8AAP8AAP8AAP8AAP8AAP8AAAD//////////////// ///////////////////////8A//////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////n5+fDAxgAA D/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAD/AAC/AAD/AAC/AAD/AAC/AAD/AAC/AAD/AAC /AAD/AAC/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/5ubm5ubmAAD/AAD/A AD/AAD/AAD/AAD/AAD/AAAA////////////////////////////////////////AP//////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////5+fnwYGMAAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAf wAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfw AAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwA AfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAfwAAAP////////////// /////////////////////////wD////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////v7+9/f39 /f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/ f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f 39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f39/f3 9/f39/f39/f39/f39/f3+fn5////////////////////////////////////////8A/////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////AP//////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////wD///////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////8A/////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////AA4AAAAUA AAAAAAAABAAAAAUAAAA 2002-08-11T06:46:41 2004-03-15T13:58:06 2004-03-15T13:58:02 2002-08-11T06:46:41 11 39 1 0 0 0 0 0 1 0 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 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 1 0 0.5 0 0 0.0033333333333333 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.11111111111111 0 0 0 0 0 0 1 0 0 0 0.01 0 1 0 2 0 0 0 2 0 1 0 0 0 0.0033333333333333 0 1 0 2 0 0 0 2 0 0 1 0 0 0 0 1 0 1 0 0 0 0 0 0 0 1 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 1 2 0.5 0 0 1 0 0 0 0.01 1 1 0 2 0 0 0 2 0 0 0 1 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 1 0 0.5 0 0 1 0 0 0 1 0 0.13888888888889 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 0 0 0 1 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 0 0 0.5 0 0 0 0 0 -1.2 0 0 0 0 1 0 0 0 1 0 0.13888888888889 0 0 0 0 0 0 0 0 1 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 0 0 0.5 0 0 1 0 0 0 1 0 0.13888888888889 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 0 0 0 1 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 1 0 0.5 0 0 2 0 0 0 1 0 0.13888888888889 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 0 0 0 1 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 0 0 0.5 0 0 2 0 0 0 1 0 0.13888888888889 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 0 0 0 1 0 0.055555555555556 0.055555555555556 0.055555555555556 0.055555555555556 0 0 0.5 0 0 0 0 0 -1.2 0 0 0 0 2 0 0 0 1 0 0.13888888888889 0 0 0 0 0 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 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 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.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.11111111111111 0 0 0 0 0 0 0 0 0 -1.2 0 0 1 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 0 18 15 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 15 1 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 15 18 1 0 1 0 0 0 0 0 0.0016666666666667 0 1 0 2 0 0 0 2 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 0 0 1 0 0.01 0 1 0 2 0 0 0 2 0 0 1 1 0 1 0 0 0 0 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 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 2 0 0 2 Visio Network Solutions
http://officupdate.com/visio/
0 0