diff --git a/Shorewall6/changelog.txt b/Shorewall6/changelog.txt deleted file mode 100644 index b86355ec6..000000000 --- a/Shorewall6/changelog.txt +++ /dev/null @@ -1,61 +0,0 @@ -Changes in Shorewall 4.2.3 - -1) Verify User/Group names. - -2) Don't allow compiled script named 'shorewall'. - -3) Avoid problems when '$' appears on the first line of -/etc/shorewall/compile. - -4) Add the output of "netstat -tunap" to dump - -5) Allow '+' as an interface. - -6) Change ipp2p detection to support latest version. - -7) Fix NEW_CONNTRACK_MATCH. - -8) Make use of --goto. - -9) Allow ressetting individual chains. - -Changes in Shorewall 4.2.2 - -1) Insure that lines copied from a user file are newline-terminated. - -2) Added macro.JAP. - -3) Added macro.DAAP. - -4) Added macro.DCC. - -5) Added macro.GNUnet. - -6) Prevent invalid rules when KLUDGEFREE is not set. - -7) Separated detection of old conntrack syntax from new conntrack - feature detection. - -8) Fix nonat rules with destination IP address. - -9) Correct NEW_CONNTRACK_MATCH with server port but no dest port. - -Changes in Shorewall 4.2.1 - -1) Added CONNBYTES to tcrules manpage. Flesh out description of HELPER. - -2) Fixed minor CONNBYTES editing issue. - -3) Add CONNLIMIT to policy and rules. - -4) Allow use of iptables-1.4.1. - -5) Add time match support. - -6) Applied Lennart Sorensen's patch for length match. - -7) Take advantage of --ctorigdstport - -8) Fix syntax error in 'export' - -Initial release of Shorewall 4.2.0. diff --git a/Shorewall6/releasenotes.txt b/Shorewall6/releasenotes.txt deleted file mode 100644 index bca5a9850..000000000 --- a/Shorewall6/releasenotes.txt +++ /dev/null @@ -1,1150 +0,0 @@ -Shorewall 4.2.3 - ----------------------------------------------------------------------------- - R E L E A S E 4 . 2 H I G H L I G H T S ----------------------------------------------------------------------------- -1) Support is included for multiple internet providers through the same - ethernet interface. - -2) Support for NFLOG has been added. - -3) Enhanced operational logging. - -4) The tarball installers now work under Cygwin. - -5) Shorewall-perl now supports IFB devices which allow traffic shaping of - incoming traffic. - -6) Shorewall-perl supports definition of u32 traffic classification - filters. - -Migration Issues. - -1) 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. - -2) 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. - -3) 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- - -4) 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: - - a) Accept the new default -- martians will be logged from all - interfaces with route filtering except those with log_martians=0 - in /etc/shorewall/interfaces. - - b) Explicitly set LOG_MARTIANS=Off to maintain compatibility with - prior versions of Shorewall. - - Shorewall-shell users may: - - a) Accept the new default -- martians will be logged from all - interfaces with the route filtering enabled. - - b) Explicitly set LOG_MARTIONS=No to maintain compatibility with - prior versions of Shorewall. - -5) The value of IMPLICIT_CONTINUE in shorewall.conf (and samples) has - been changed from Yes to No. - -6) 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. - -7) DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl. Use - ipset-based zones instead. - -Problems corrected in Shorewall 4.2.3 - -1) Previously, Shorewall would allow compilation for export of a - script named 'shorewall' with the unfortunate side effect that - the 'shorewall.conf' file was overwritten. Scripts named - 'shorewall' now cause a fatal error to be raised. - -2) Previously, Shorewall-perl attempted to do Shell variable - substitution on the first line in /etc/shorewall/compile. - -3) Following the Netfilter tradition, the IPP2P maintainer has made an - incompatible syntax change (the --ipp2p option has been - removed). Shorewall has always used "-m ipp2p --ipp2p" when - detecting the presence of IPP2P support. - - Shorewall-common and Shorewall-perl have been modified to use - "-m ipp2p --edk" instead. - -4) When Extended Conntrack Match support was available, Shorewall-perl - would create invalid iptables-restore input for certain DNAT rules. - -Other changes in Shorewall 4.2.3 - -1) Except with the -e option is specified, the Shorewall-perl compiler - now verifies user/group names appearing in the USER/GROUP column of - the rules file. - -2) The output of 'shorewall dump' now includes the output from - 'netstat -tunap'. - -3) Shorewall-perl now accepts '+' as an interface name in - /etc/shorewall/interfaces. That name matches any interface and is - useful for defining a zone that will match any interface that might - be added after Shorewall is started. - - A couple of words of caution are in order. - - a) Because '+' matches any interface name, Shorewall cannot - verify interface names appearing in other files when '+' is - defined in /etc/shorewall/interfaces. - - b) The zone assigned to '+' must be the last one defined in - /etc/shorewall/zones. - -4) Shorewall-perl now uses the iptables --goto parameter in obvious - cases. - -5) The 'reset' command now allows you to reset the packet and byte - counter on individual chains: - - shorewall reset chain1 chain2 ... - shorewall-lite reset chain1 chain2 ... - -New Features in Shorewall 4.2 - -1) Shorewall 4.2 contains support for multiple Internet providers - through a single ethernet interface. Configuring two providers - through a single interface differs from two providers through two - interfaces in several ways. - - a) Only ethernet (or ethernet-like) interfaces can be used. For - inbound traffic, the MAC addresses of the gateway routers is used - to determine which provider a packet was received through. Note - that only routed traffic can be categorized using this technique. - - b) You must specify the address on the interface that corresponds to - a particular provider in the INTERFACE column by following the - interface name with a colon (":") and the address. - - c) Entries in /etc/shorewall/masq must be qualified by the provider - name (or number). - - d) This feature requires Realm Match support in your kernel and - iptables. If you use a capabilities file, you need to regenerate - the file with Shorewall 4.2 or Shorewall-lite 4.2. - - e) You must add route_rules entries for networks that are accessed - through a particular provider. - - f) If you have additional IP addresses through either provider, - you must add route_rules to direct traffic FROM each of those - addresses through the appropriate provider. - - g) You must add MARK rules for any traffic that you know originates - from a particular provider. - - Example: - - Providers Blarg (1) and Avvanta (2) are both connected to - eth0. The firewall's IP address with Blarg is 206.124.146.176/24 - (gateway 206.124.146.254) and the IP address from Avvanta is - 130.252.144.8/24 (gateway 130.252.144.254). We have a second IP - address (206.124.146.177) from Blarg. - - /etc/shorewall/providers: - - #PROVIDER NUMBER MARK DUPLICATE INTERFACE GATEWAY - Blarg 1 1 main eth0:206.124.146.176 206.124.146.254 ... - Avvanta 2 2 main eth0:130.252.144.8 130.252.144.254 ... - - /etc/shorewall/masq: - - #INTERFACE SOURCE ADDRESS - eth0(Blarg) 130.252.144.8 206.124.146.176 - eth0(Avvanta) 206.124.146.176 130.252.144.8 - eth0(Blarg) eth1 206.124.146.176 - eth0(Avvanta) eth1 130.252.144.8 - - /etc/shorewall/route_rules: - - #SOURCE DEST PROVIDER PRIORITY - - 206.124.146.0/24 Blarg 1000 - - 130.252.144.0/24 Avvanta 1000 - 206.124.146.177 - Blarg 26000 - - /etc/shorewall/tcrules - - #MARK/CLASSIFY SOURCE DEST - 1 eth0:206.124.146.0/24 0.0.0.0/0 - 2 eth0:130.242.144.0/24 0.0.0.0/0 - -2) You may now include the name of a table (nat, mangle or filter) in - a 'shorewall refresh' command by following the table name with a - colon (e.g., mangle:). This causes all non-builtin chains in the - table to be reloaded. - - Example: - - shorewall refresh nat: - -3) When no chain name is given to the 'shorewall 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 'shorewall refresh'. - -4) Support for the NFLOG log target has been added. NFLOG is a - successor to ULOG. In addition, 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: - - ACCEPT:NFLOG(1,0,1) vpn fw tcp ssh,time,631,8080 - -5) Shorewall-perl 4.2 implements an alternative syntax for macro - parameters and for the NFQUEUE queue number. Rather than following - the macro name (or NFQUEUE) with a slash ("/") and the parameter, - the parameter may be enclosed in parentheses. - - Examples -- each pair shown below are equivalent: - - DNS/ACCEPT DNS(ACCEPT) - NFQUEUE/3 NFQUEUE(3) - - The old syntax will still be accepted but will cease to be documented - in some future Shorewall release. - -6) Shorewall 4.2 contains enhanced operational logging capabilities - through a set of related enhancements to Shorewall-common and - Shorewall-perl. The enhancements are not supported by - Shorewall-shell nor are they supported by Shorewall-lite except - when the script is compiled using Shorewall-perl. - - a) The STARTUP_LOG option in /etc/shorewall/shorewall.conf gives - the name of the Shorewall operational log. The log will be - created if it does not exist. - - b) The LOG_VERBOSITY option in /etc/shorewall/shorewall.conf gives - the verbosity at which logging will occur. It uses the same - value range as VERBOSITY: - - -1 Do not log - 0 Almost quiet - 1 Only major steps - 2 Verbose - - c) An absolute VERBOSITY may be specified on the command line - using the -v option followed by -1,0,1 or 2. - - Example: - - shorewall -v2 check - - d) The /etc/init.d/shorewall script supplied with the - shorewall.net packages sets '-v0' as the default. This may be - overridden with the OPTIONS setting in /etc/defaults/shorewall or - /etc/sysconfig/shorewall. - - Logging occurs on both Shorewall-perl and the generated script when - the following commands are issued: - - start - restart - refresh - - Messages in the log are always timestamped. - - This change implemented two new options to the Shorewall-perl - compiler (/usr/share/shorewall-perl/compiler.pl). - - --log= - --log_verbosity={-1|0-2} - - The --log option is ignored when --log_verbosity is not supplied or - is supplied with value -1. - - To avoid a proliferation of parameters to - Shorewall::Compiler::compile(), that function has been changed to - use named parameters. Parameter names are: - - object Object 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. - - Those parameters that are supplied must have defined values. - - Defaults are: - - object '' ('check' command) - directory '' - verbosity 1 - timestamp 0 - debug 0 - export 0 - chains '' - log '' - log_verbosity -1 - - - Example: - - use lib '/usr/share/shorewall-perl/'; - use Shorewall::Compiler; - - compiler( object => '/root/firewall', - log => '/root/compile.log', - log_verbosity => 2 ); - -7) 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 chain. - -8) 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. - -9) The tcdevices file has been extended to include an OPTIONS - column. Currently only a single option is defined. - - classify When specified, you must use explicit CLASSIFY tcrules - to classify traffic by class. Shorewall will not create - any CLASSIFY rules to classify traffic by mark value. - - See http://www.shorewall.net/traffic_shaping.htm for further - information. - -10) COMMENT lines are now supported in macro bodies by Shorewall-perl - and are ignored by the Shorewall-shell compiler. - - COMMENT lines in macros work slightly differently from COMMENT - lines in other files. COMMENT lines in macros are ignored if - COMMENT support is not available or if there was a COMMENT in use - when the top-level macro was invoked. This allows the - following: - - /etc/shorewall/macro.SSH: - - #ACTION SOURCE PROTO DEST SOURCE RATE USER/ - # PORT(S) PORT(S) LIMIT GROUP - COMMENT My SSH Macro - PARAM - - tcp 22 - - /etc/shorewall/rules: - - COMMENT Allow SSH from home - SSH/ALLOW net:$MYIP $FW - COMMENT - - The comment line in macro.SSH will not override the - COMMENT line in the rules file and the generated rule will show - - /* Allow SSH from home */ - - when displayed through the Shorewall show and dump commands. - - If a macro is invoked and there is no current comment, then the - name of the macro automatically becomes the current comment. This - makes macros self-commenting. - -11) If the program named in SHOREWALL_SHELL doesn't exist or is not - executable, Shorewall and Shorewall-lite now both fall back to - /bin/sh after issuing a warning message. Previously, both - terminated with a fatal error. - -12) Shorewall-perl now generates fatal error conditions if there are - no IPv4 zones defined or there are no interfaces defined. - -13) Shorewall now unconditionally uses tc filter rules to classify - traffic by MARK value. Previously, Shorewall used the CLASSIFY - target in the POSTROUTING chain if it was available. - -14) The Shorewall installers (install.sh) now work on Windows - under Cygwin. By default, they install under the user id and group - of the person doing the install. This can be overridden by - specifying OWNER and GROUP explicitly. - - Example: - - OWNER=foo GROUP=bar ./install.sh - - To install Shorewall-perl under Cygwin: - - $ tar -zxf shorewall-perl-4.x.y.tar.bz2 - $ tar -zxf shorewall-common-4.x.y.tar.bz2 - $ cd shorewall-perl-4.x.y - $ ./install.sh - $ cd ../shorewall-common-4.x.y - $ ./install.sh - - The 'shorewall' program is installed in /bin/ (a.k.a, /usr/bin/). - -15) When installing on Cygwin, /etc/shorewall is no longer fully - populated. Rather, only the shorewall.conf and params files are - installed. As always, the full configuration file set is installed - in /usr/share/shorewall/configfiles. - -16) 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- - -17) The /etc/shorewall/masq and /etc/shorewall/nat file now accept a - comma-separated list of interface names where before only a single - interface name could be listed (Shorewall-perl only). - - This feature is not for beginners. It iterates over the - list of interfaces, substituting each interface in place of the - list and processing the resulting entry according to the semantics - of earlier Shorewall versions. If you don't know where to use this, - don't try. - - Example 1: - - /etc/shorewall/masq: - - #INTERFACE SOURCE ADDRESS - eth0,eth1 eth2 1.2.3.4 - - equivalent to: - - #INTERFACE SOURCE ADDRESS - eth0 eth2 1.2.3.4 - eth1 eth2 1.2.3.4 - - Example 2: - - /etc/shorewall/masq: - - #INTERFACE SOURCE ADDRESS - eth0,eth1::192.168.1.0/24 eth2 1.2.3.4 - - equivalent to: - - #INTERFACE SOURCE ADDRESS - eth0::192.168.1.0/24 eth2 1.2.3.4 - eth1::192.168.1.0/24 eth2 1.2.3.4 - - Example 3: - - /etc/shorewall/nat: - - #EXTERNAL INTERFACE INTERNAL - 206.124.146.178 eth0,wlan0 192.168.1.3 - - equivalent to: - - #EXTERNAL INTERFACE INTERNAL - 206.124.146.178 eth0 192.168.1.3 - 206.124.146.178 wlan0 192.168.1.3 - -18) Previously, the INTERFACE name used in the masq, nat and netmap - files had to exactly match the name of an interface from the - interfaces file. Beginning with Shorewall-perl 4.1.4, the - interface may loosely match a wildcard entry in the interfaces - file. - - Example: - - /etc/shorewall/interfaces: - - vpn tun+ - - /etc/shorewall/masq: - - tun1 192.168.4.0/24 - -19) Previously, Shorewall classified non-firewall zones as either - 'simple' or 'complex'. Attributes of a zone which made it 'complex' - included: - - - The zone was of type 'ipsec' or 'ipsec4' or it had a hosts - entry with the 'ipsec' options. - - The zone had OPTIONS, IN OPTIONS or OUT OPTIONS - - The zone had more than one network on a given interface - - The zone had a hosts file entry with an exclusion. - - The zone had a hosts file entry specifying an ipset. - - The handling of 'simple' and 'complex' zones was different. - - - complex zones had their own 'forward' chain (named - '_frwd'). - - complex zones with exclusions had their own 'input' and - 'output' chains. - - Beginning with Shorewall-perl 4.2, all non-firewall zones will be - treated as 'complex'. This will have the effect of one additional - filter chain per zone but in most cases, the average number of - filter rules traversed by a connection request will be reduced. - -20) The need for interface-specific chains (such as eth0_in, eth4_fwd, - etc.) in the filter table has been drastically reduced. This has - the effect of reducing the average number of rules that each packet - must traverse. - -21) The default value for LOG_MARTIANS is now 'Yes' ('On' in - Shorewall-perl). Previously, the default value was 'No' ('Off' in - Shorewall-perl). The shorewall.conf file has also been - updated to specify a value of 'Yes' (which is interpreted as 'On' - by Shorewall-perl). - -22) Shorewall-perl now generates an error when a MAC address appears in - a traffic shaping rule in the OUTPUT or POSTROUTING chains. - -23) Macros are now self-commenting under control of a new AUTO_COMMENT - option in shorewall.conf. When this option is set, if there is not - a current comment when a macro is invoked, the behavior under - Shorewall-perl is as if the first line of the macro file was - "COMMENT ". - - So, if you have this rule: - - SSH/ACCEPT loc fw - - then the generated netfilter rule will include "/* SSH */" when - viewed with 'iptables -L' or 'shorewall show loc2fw' or 'shorewall - dump'. - - The AUTO_COMMENT option has a default value of 'Yes' and is only - available under Shorewall-perl. The option is ignored by - Shorewall-shell. - -24) The default value for the IMPLICIT_CONTINUE option has been changed - to 'No'. - -25) Shorewall-perl now supports an 'l2tp' tunnel type. It opens UDP - port 1701 in both directions and assumes that the source port will - also be 1701. Some implementations (particularly OS X) use a - different source port. In that case, you should use - 'generic:udp:1701' rather than 'l2tp'. - -26) The /etc/shorewall/tcdevices and /etc/shorewall/tcclasses files - have undergone some changes, especially when the 'classify' option - has been specified. - - Normally Shorewall assigns interface numbers sequentially to - devices listed in /etc/shorewall/tcdevices. Beginning with - Shorewall 4.1.6, you can explicitly specify inteface numbers by - prefixing the interface name with the interface number and a colon: - - Example: - - #INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS - 1:eth0 1300kbit 384kbit classify - 2:eth1 5600kbit 1000kbit - - In /etc/shorewall/tcclasses: - - a) You can specify the INTERFACE using either the interface name - or interface number. - - b) classes associated with devices which have the 'classify' - option _must_ specify a class number by following the interface - name/number with a colon (":") and the class number. The same - class number may be used for classes defined on different - interfaces but a class number may not be the same as any - interface number. - - A class number may be specified when 'classify' has not been - specified for the associated device. When a class number has not - been given, the default class number remains the mark value - prefixed by "1". - -27) Shorewall now supports Intermediate Functional Block (IFB) devices. - These devices allow shaping of incoming traffic. - - The 'ifb' module is available in the kernels included with today's - distributions. You must load the module manually: - - If your distribution has modprobe: - - modprobe ifb [ numifbs= ] - - Otherwise: - - insmod /ifb.ko [ numifbs= ] - - By default, the module automatically creates two IFB devices (ifb0 - and ifb1). To create only one, specify 'numifbs=1'. - - Example: - - ursa:~ # modprobe ifb numifbs=1 - ursa:~ # ip link ls - 1: lo: mtu 16436 qdisc noqueue - link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 - 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 - link/ether cc:2b:cb:24:1b:00 brd ff:ff:ff:ff:ff:ff - 3: wlan0: mtu 1500 qdisc pfifo_fast qlen 1000 - link/ether 00:1a:73:db:8c:35 brd ff:ff:ff:ff:ff:ff - 4: ifb0: mtu 1500 qdisc noop qlen 32 - link/ether 26:99:d8:7d:32:26 brd ff:ff:ff:ff:ff:ff - ursa:~ # - - After you have created the IFB(s), you must bring it(them) up: - - ip link set dev ifb0 up - - You can place all of this in /etc/shorewall/init as follows: - - modprobe ifb numifbs=1 - ip link set dev ifb0 up - - The /etc/shorewall/tcdevices file has been extended to include an - additional REDIRECTED DEVICES column. To convert your configuration - to use an IFB: - - a) Look at your current /etc/shorewall/tcdevices file. Suppose you - have: - - #INTERFACE IN-BANDWIDTH OUT-BANDWIDTH OPTIONS - eth0 1300kbit 384kbit - - - Change it as follows: - - #INTERFACE IN-BANDWIDTH OUT-BANDWIDTH OPTIONS REDIRECTED - # DEVICES - eth0 - 384kkbit - - ifb0 - 1300kbit - eth0 - - Note that the old IN-BANDWIDTH for eth0 has become the - OUT-BANDWIDTH for ifb0 and that neither device has an - IN-BANDWIDTH in the new configuration. - - Finally note that eth0 has been specified as a REDIRECTED device - for the IFB. - - b) There are no Netfilter hooks between the real device (eth0) and - the IFB (ifb0). So tcrules cannot be used to specify shaping of - traffic leaving the IFB. To allow that traffic to be classified, - a new /etc/shorewall/tcfilters file has been added. - - /etc/shorewall/tcfilters can be used for classifying traffic on - any interface. When using entries in that file, it is important - to realize that those entries act on packets as they appear 'on - the wire'. That means that on output, SNAT/MASQUERADE has been - applied and on input (output to an IFB), DNAT has not yet been - applied. - - Columns in the file are: - - INTERFACE:CLASS - - The interface name or number followed by a colon (":") - and the class number. - - SOURCE - Source IP address. May be a host or network address. - Specify "-" if any SOURCE address should match. - - DEST - Destination IP address. May be a host or network - address. Specify "-" if any DEST address should match. - - PROTO - Protocol Name/Number. Specify "-" if any PROTO should - match. - - DEST PORT(S) - A comma-separated list of destination ports. May only - be given if the PROTO is tcp, udp, icmp or - sctp. Port ranges may be used, except when the PROTO is - icmp. Specify "-" if any PORT should match. - - SOURCE PORT(S) - A comma-separated list of source port. May only be - given if the PROTO is tcp, udp or sctp. Port ranges - may be used unless the protocol is icmp. Specify "-" if - any PORT should match. - - Entries in /etc/shorewall/tcfilters generate U32 tc filters which - may be displayed using the "shorewall show filters" ("shorewall-lite - show filters") command. Note: The 'show filters' command is an - alias for the existing 'show classifiers' command. - - Note that /etc/shorewall/tcfilters provides a usable alternative to - HIGH_ROUTE_MARKS=Yes. You can use marks to select between providers - and use entries in /etc/shorewall/tcfilters (or CLASSIFY tcrules) - for traffic shaping. - -28) If an interface fails when using balanced multi-ISP routing, the - default route is lost. If there are remaining working interfaces - with dynamic gateway addresses, Shorewall will be unable to - determine those gateways. - - Beginning with Shorewall (Shorewall-lite) 4.1.7, the 'init' script - may participate in gateway detection by setting variables with - pre-determined names as follows: - - _GATEWAY - - where is the interface name: - - - in upper case - - with any characters not allowed in shell variable names - replaced by '_'. - - Example (from OpenWRT): - - Interface: eth0.1 - Variable: ETH0_1_GATEWAY - /etc/shorewall/init: - - ETH0_1_GATEWAY=$(uci get /var/state/network.wan0.gateway) - -29) A new CONNBYTES column has been added to the tcrules file. The - column defines a byte or packet range that the connection must fall - within in order for the rule to match. The contents are: - - [!]:[[:{O|R|B}[:{B|P|A}]]] - - ! matches if the the packet/byte count is not within the range - defined by and . - - is an integer which defines the beginning of the byte/packet - range. - - 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 determins what the range refers to. - - B - Bytes - P - Packets - A - Average packet size. - - If omitted, 'B' is assumed. - - Examples: - - 1000000: - Connection has transferred a total of - at least 1,000,000 bytes. - - 1000000::R - Connection has transferred at least - 1,000,000 bytes in the direction opposite - of the original direction (typical of a - large download). - - 1000000::O:P - Connection has sent at least 1,000,000 - packets in the direction of the original - connection. - -30) A new MANGLE_ENABLED option is added to shorewall.conf. The default - setting is 'Yes' which causes Shorewall to assume responsibility for - the Netfilter mangle table. - - When MANGLE_ENABLED is set to 'No', Shorewall assumes no - responsibility for that table. In this setting: - - a) Shorewall doesn't alter the mangle table. - b) You may not use Shorewall Traffic Shaping (TC_ENABLED must be - set to 'No'. - c) The tcrules file is ignored. - d) The providers file must be empty. - e) All entries in tcdevices must specify the 'classify' option and - traffic classification may only occur using the tcfilters file. - - This allows for another application running on your firewall to - take over the mangle table and use it for it's own purposes. - -31) Shorewall-perl now supports an ORIGINAL DEST column in macro files. - The column must be left empty if the macro is to be used in the - body of an action. - - The new column is placed between the SOURCE PORT(S) and RATE LIMIT - columns. So that Shorewall-perl can determine which column layout - each macro has, a new FORMAT directive is added: - - FORMAT {1|2} - - The default is FORMAT 1 which is the old format. FORMAT 2 specifies - that the macro is in the new format. - -32) Shorewall-perl implements a new Rfc1918 macro that deals with - RFC 1918 addresses. This macro should be used in place of - the 'norfc1918' interface option which is deprecated. - - The macro body is: - - #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ - # PORT(S) PORT(S) DEST LIMIT GROUP - FORMAT 2 - PARAM SOURCE:10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 \ - DEST - - - - - - - PARAM SOURCE DEST - - - 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 - #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE - - The 'norfc1918' option on the interface associated with zone 'z' - and with RFC1018_STRICT=Yes is equivalent to: - - Rfc1918(DROP) z all - -33) A better way to perform RFC 1918 filtration is to null-route the - address ranges reserved by RFC 1918. You can do that by setting the - new NULL_ROUTE_RFC1918 option to 'Yes' in shorewall.conf. - - It is highly recommended that you also set ROUTE_FILTER=Yes to get - Martian messages. These will help diagnose problems where you need - to be able to access hosts with RFC 1918 addresses that are outside - of your local networks. Sometimes, these can be subtle such as the - case where your ISP is using RFC 1918 addresses on their DHCP - servers. - - NULL_ROUTE_RFC1918 defaults to 'No' and is only supported by - Shorewall-perl; Shorewall-shell ignores the option. - -34) There is now a macro.SANE which supports network-attached - scanners. Shorewall now automatically loads the sane connection - tracking helper module. - - Thanks for this feature go to Tuomo Soini. - -35) Previously, when IP_FORWARDING=Yes in shorewall.conf, Shorewall - would enable ip forwarding before instantiating the rules. This - could lead to incorrect connection tracking entries being created - between the time that forwarding was enabled and when the nat table - rules were instantiated. - - Beginning with Shorewall 4.0.11 and 4.1.7, enabling of forwarding - is deferred until after the rules are in place. - -36) When using Shorewall-perl, the CEIL and RATE columns must now - contain arithmetic expressions consisting of: - - a) Numeric digits (Hex numbers not allowed). - b) Parentheses. - c) The arithmetic operators +-* and /. - d) The word 'full'. - -37) The installers (install.sh) now auto-detect a Cygwin environment - and install under the current user's ID if OWNER and GROUP are not - given. - -38) The 'start' and 'restart' commands now support a '-p' (purge) - option which cause all entries to be removed from the Netfilter - conntrack table. In order to use this option, the 'conntrack' - utility must be installed on your system. Although it is generally - not installed by default, Most distributions have this utility in - their repositories. - -39) A 'save' extension script is added. The script is run after - iptables-save has completed successfully. - - The 'load' and 'reload' commands copy the save script (if any) to - /etc/shorewall-lite/ on the remove firewall system. The 'export' - command copies the file to the same directory as the 'firewall' and - 'firewall.conf' scripts. - - I have the following commands in my 'save' script: - - [ -s /root/ipsets.save ] && cp -a /root/ipsets.save /root/ipsets.save.backup - ipset -S > /root/ipsets.save - - These commands complement my 'init' script: - - qt modprobe ifb numifbs=1 - qt ip link set dev ifb0 up - - if [ "$COMMAND" = start ]; then - ipset -U :all: :all: - ipset -U :all: :default: - ipset -F - ipset -X - ipset -R < /root/ipsets.save - fi - - Those two scripts allow me to save and restore the contents of my - ipsets automatically under Shorewall-perl/Shorewall-lite (my - routestopped file does not use ipsets). - -40) A HELPER column is included in the tcrules file. The value in this - column names one of the Netfilter protocol 'helper' module sets - (ftp, sip, amanda, etc). - - See http://www.shorewall.net/traffic_shaping.htm for an example. - -41) DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl. - -42) Farkas Levante has contributed a macro.Mail macro that covers SMTP, - SMTPS and submission. - -43) Beginning with Shorewall 4.0.0, the -f option was no longer the - default for '/etc/init.d/shorewall start'. Beginning with 4.0.13 - and 4.2.0-Beta3, this is also true for Shoreawall-lite. - -44) A new USE_DEFAULT_RT option has been added to shorewall.conf. When - set to 'Yes', it 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: - - a) Both the DUPLICATE and the COPY columns in the providers file - must remain empty (or contain "-"). - - b) The default route is added to the the 'default' table rather - than to the main table. - - c) 'balance' is assumed unless 'loose' is specified. - - d) Packets are sent through the main routing table by a rule with - priority 999. In /etc/shorewall/routing_rules, the range 1-998 - may be used for inserting rules that bypass the main table. - - e) All provider gateways must be specified explicitly in the - GATEWAY column. 'detect' may not be specified. - - f) 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). - -45) The 'shorewall restart' command now supports an -f option. When - this option is specified, no compilation occurs; rather, the script - which last started or restarted Shorewall is used. - -46) A macro supporting RNDC (BIND remote management protocol) traffic - has been added. It can be used as any other macro (e.g., RNDC/ACCEPT) - in the rules file. - -47) If 'NONAT' is specified in the ADDRESS column of an entry in - /etc/shorewall/masq, then traffic matching that entry is not - passed to the entries that follow. - -New Features added in Shorewall 4.2.1 - -1) With the recent renewed interest in DOS attacks, it seems - appropriate to have connection limiting support in Shorewall. To - that end, a CONNLIMIT column has been added to both the policy and - rules files. - - The content of these columns is of the format - - [!] [:] - - where - - is the limit on simultaneous TCP connections. - - specifies the size of the network to which - the limit applies and is specified as a - CIDR mask length. The default value for - is 32 which means that each remote - IP address can have TCP connections - active at once. - - ! Not allowed in the policy file. In the rules file, it - causes connections to match when the number of - current connections exceeds . - - When specified in the policy file, the limit is enforced on all - connections that are subject to the given policy (just like - LIMIT:BURST). The limit is checked on new connections before the - connection is passed through the rules in the NEW section of the - rules file. - - It is important to note that while the limit is only checked for - those destinations specified in the DEST column, the number of - current connections is calculated over all destinations and not - just the destination specified in the DEST column. - - Use of this feature requires the connlimit match capability in your - kernel and iptables. If you use a capabilities file when compiling - your Shorewall configuration(s), then you need to regenerate the - file using Shorewall or Shorewall-lite 4.2.1. - -2) Shorewall now supports time/date restrictions on entries in the - rules file via a new TIME column. - - The contents of this column is a series of one or more "time - elements" separated by apersands ("&"). Possible time elements are: - - utc Times are expressed in Greenwich Mean Time. - localtz Times are expressed in local civil time (default) - timestart=hh:mm[:ss] - timestop=hh:mm[:ss] Start and stop time of day for rule - weekdays=ddd[,ddd]... where ddd is Mon,Tue,Wed,Thu,Fri,Sat or - Sun - monthdays=dd[,dd]... where dd is an ordinal day of the month. - datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]] - datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]] - where yyyy = Year - first mm = Month - dd = Day - hh = Hour - 2nd mm = Minute - ss = Second - - Examples: - - 1) utc×tart=10:00×top=12:00 - - Between 10am and 12 noon each day, GMT - - 2) datestart=2008-11-01T12:00 - - Beginning November 1, 2008 at noon LCT. - - Use of this feature requires the time match capability in your - kernel and iptables. If you use a capabilities file when compiling - your Shorewall configuration(s), then you need to regenerate the - file using Shorewall or Shorewall-lite 4.2.1. - -3) If your kernel and iptables support "-m conntrack --ctorigdstport" - then Shorewall will utilize that capability to ensure that when you - do port mapping (change the destination port but not the - destination IP address), the final destination port is not opened - as a side effect. - - Example: - - DNAT net loc:206.124.146.177:22 tcp 2222 - 206.124.146.177 - - That rule maps port 2222 -> 22 but without this new feature, it - also opens port 22 directly. - - To use this feature, you must be running Shorewall-perl and the - output of 'shorewall show capabilities' must show: - - Extended Connection Tracking Match Support: Available - -New Featurs in Shorewall 4.2.2 - -1) A macro supporting JAP (anonymization protocol) has been added. - It can be used as any other macro (e.g., JAP/ACCEPT) in the rules - file. - -2) A macro supporting DAAP (Digital Audio Access Protocol) has been added. - It can be used as any other macro (e.g., DAAP/ACCEPT) in the rules - file. - -3) A macro supporting DCC (Distributed Checksum Clearinghouse) has been - added. It can be used as any other macro (e.g., DCCP/ACCEPT) in the - rules file. - -4) A macro supporting GNUnet (secure peer-to-peer networking) has been - added. It can be used as any other macro (e.g., GNUnet/ACCEPT) in the - rules file. - -5) In 4.2.1, a single capability ("Extended conntrack match support") - was used both to control the use of --ctorigport and to trigger use - of the new syntax for inversion of --ctorigdst (e.g., "! - --ctorigdst ..."). In 4.2.2, these are controlled by two separate - capabilities. If you use a capabilities file when compiling your - configuration, be sure to generate a new one after installing - 4.2.2. - -Problems corrected in Shorewall 4.2.1 - -1) A description of the CONNBYTES column has been added to - shorewall-tcrules(5). - -2) Previously, Shorewall-perl would accept zero as the value in - the CONNBYTES column of tcrules even when the field was - non-zero. A value of zero for was equivalent to omitting - . - -3) iptables 1.4.1 discontinued support of syntax generated by - shorewall in some cases. Shorewall now detects when the new syntax - is required and uses it instead. - -4) The Shorewall-perl implementation of the LENGTH column in - /etc/shorewall/tcrules was incomplete with the result that - all LENGTH rules matched. Thanks to Lennart Sorensen for the patch. - -5) The 'export' command no longer fails with the error: - - /sbin/shorewall: 1413: Syntax error: "(" unexpected (expecting "fi") - -Problems corrected in Shorewall 4.2.2 - -1) Shorewall-perl now insures that each line copied from a - configuration file or user exit is terminated with a newline - character. - -2) When ipranges were used to define zones, Shorewall-perl could - generate invalid iptables-restore input if 'Repeat Match' was not - available. Repeat Match is not a true match -- it rather is a - feature of recent iptables releases that allows a match to be - repeated within a rule. - -3) With Shorewall-perl, if a destination port list had exactly 16 - ports, where a port-range counts as two ports, then Shorewall-perl - would fail to split the rule into multiple rules and an - iptables-restore error would result. - -4) The change to Shorewall-perl in 4.2.1 that promised iptables 1.4.1 - compatibility contained a typo that prevented it from working - correctly. - -5) If a no-NAT rule (DNAT-, ACCEPT+, NONAT) included a destination IP - address and no zone name in the DEST column, Shorewall-perl would - reject the rule. If a zone name was specified, Shorewall-perl - would issue a Warning message. -