forked from extern/shorewall_code
69d5712047
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@6958 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
9892 lines
524 KiB
HTML
9892 lines
524 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<title>Old News </title>
|
|
</head>
|
|
|
|
<body>
|
|
<span style="font-weight: bold;">2007-02-10 Shorewall 3.2.9<br>
|
|
</span>
|
|
<pre>Problems Corrected in 3.2.9<br><br>1) While most distributions store the Shorewall Lite compiled program<br> in /var/lib/shorewall-lite/, Shorewall includes features that allow<br> that location to be changed on a per-distribution basis. The<br> default for a particular distribution may be determined by the<br> command "shorewall[-lite] show config".<br><br> teastep@lists:~/shorewall/trunk$ shorewall show config<br> Default CONFIG_PATH is /etc/shorewall:/usr/share/shorewall<br> LITEDIR is /var/lib/shorewall-lite<br> teastep@lists:~/shorewall/trunk$<br><br> The LITEDIR setting is the location where the compiled script<br> should be placed. Unfortunately, the "shorewall [re]load" command<br> previously used the setting on the administrative system rather<br> than the one from the firewall system so it was possible for that<br> command to upload the compiled script to the wrong directory.<br><br> To work around this problem, Shorewall now determines the LITEDIR<br> setting on the firewall system and uses that setting for uploading<br> the compiled script and its companion .conf file.<br><br>2) Previously, IP ranges and ipset names were handled incorrectly in<br> the last column of the maclist file with the result that run-time<br> errors occured.<br><br>3) The new SIP and H323 Netfilter helper modules were not being<br> automatically loaded by Shorewall. They have now been added to the<br> /usr/share/shorewall[-lite]/modules files.<br><br>Other Changes in 3.2.9<br><br>1) Previously, 'ipsecnat' tunnels allowed AH traffic by default<br> (unless 'isecnat:noah' was given). Given that AH is incompatible<br> with nat-traversal, 'ipsecnat' now implies 'ipsecnat:noah'.<br><br>2) A macro that handles SixXS has been contributed by Christian<br> Roessner.<br><br>3) It is rather difficult to code a 'params' file that assigns other<br> than constant values such that it works correctly with Shorewall<br> Lite. To work around this problem, a new EXPORTPARAMS option<br> has been added to shorewall.conf. When EXPORTPARAMS=No, the<br> 'params' file is no longer copied to the compiler output.<br><br> With EXPORTPARAMS=No, if you need to set environmental variables on<br> the firewall system for use by your extension scripts, then do so<br> in the init extension script.<br><br> The default is EXPORTPARAMS=Yes to retain the current behavior. So<br> if you are happy with the current behavior, you need make no change<br> to your shorewall.conf file.<br></pre>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;"></span><span>style="font-weight:
|
|
bold;">2007-01-16 Shorewall 3.2.8<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Problems Corrected in 3.2.8<br><br>1) The 'ash' shell produced an error when processing an entry with a<br> log tag from /etc/shorewall/rules.<br><br>2) If the file /etc/shorewall/init did not exist, then the compiler<br> would incorrectly copy /usr/share/shorewall/init into the<br> compiled script. /usr/share/shorewall/init is a symbolic link<br> to the Shorewall init script (usually /etc/init.d/shorewall).<br><br>3) Previously, "ipp2p:udp" was incorrectly rejected in the PROTO<br> column of an action definition.<br><br>Other Changes in 3.2.8.<br><br>1) New macros for network printing protocols have been added,<br> courtesy of Tuomo Soini. Tuomo also provided a macro for TFTP.<br><br> The print-oriented macros are:<br><br> macro.IPP<br> macro.Jetdirect<br> macro.Printer<br></pre>
|
|
<span style="font-weight: bold;"></span><span
|
|
style="font-weight: bold;"></span>
|
|
<pre><span style="font-weight: bold;"></span></pre>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<pre><span style="font-weight: bold;">2006-12-14 Shorewall 3.2.7</span><br></pre>
|
|
<pre>Problems Corrected in 3.2.7<br><br>1) Handling of saved ipsets in /etc/shorewall/ipsets is broken when<br> used on a system running Shorewall Lite. If there is a file named<br> 'ipsets' on the CONFIG_PATH when the firewall script is compiled,<br> then the compiled script attempts to restore the ipsets from that<br> file (which may not exist on the firewall system).<br><br>2) The 'try' command failed on systems whose /bin/sh is Busybox ash:<br><br> /sbin/shorewall: export: 2158: Illegal option -n<br><br>3) Previously, Shorewall has assumed that the root user is named<br> 'root'. Beginning with this release, the root user may have a<br> different name. This required the addition of an '-r' option for<br> the 'shorewall load' and 'shorewall reload' commands.<br><br> [re]load [ -e ] [ -c ] [ -r <root user> ] [ <dir> ] system<br><br> Example: shorewall reload -r foobar firewall<br><br>4) On systems with a light-weight shell such as ash or dash for /bin/sh,<br> the output of "shorewall show macros" was garbled.<br><br>Other Changes in 3.2.7<br><br>1) Prior to this release, on firewall systems with Shorewall Lite<br> installed, the local modules file is used to determine which kernel<br> modules to load. Beginning with this release, if there is a<br> 'modules' file in the export directory when the firewall script is<br> compiled, then that file will be copied into the compiled script<br> and used on the firewall system.<br><br>2) When syslogd is run with the -C option (which in some<br> implementations causes syslogd to log to an in-memory circular<br> buffer), /sbin/shorewall will now use the 'logread' command to read<br> the log from that buffer. This is for combatibility with OpenWRT.<br><br>3) Failures of the start, restart and restore commands are now logged<br> using 'logger'. These failures are logged with the 'kern' facility <br> and 'err' priority. As part of this change, normal state changes<br> are now logged with the 'kern' facility and 'info' priority.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-11-18 Shorewall 3.2.6<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Problems Corrected in 3.2.6.<br><br>1) When using a light-weight shell (e.g., ash) with multiple<br>providers, the /etc/iproute2/rt_tables database may become corrupted.<br><br>2) A startup error occurred when the LENGTH or TOS column was<br> non-empty in /etc/shorewall/tcrules.<br><br>3) A startup error resulted when whitespace as included in LOGFORMAT.<br><br>4) Previously, when conntrack match support was not available, the<br> 'norfc1918' option on an interface or host group was incorrectly<br> filtering IPSEC traffic whose source IP address was reserved by RFC<br> 1918.<br><br>5) If a DNAT or REDIRECT rule was used where the effective policy<br> between the source and final destination zones is ACCEPT, the ACCEPT<br> part of the rule was not generated. This was intended as an<br> optimizaiton but it could lead to confusing results if there was a<br> DROP or REJECT rule following.<br><br> This optimization has been removed. You may always use DNAT- and<br> REDIRECT- to suppress generation of the ACCEPT rule.<br><br>6) Shorewall[-lite] previously would return an error exit status to a<br> "start" command where Shorewall was already running. It not returns<br> a "success" status.<br><br>7) The install.sh scripst have been corrected to work properly when <br> used to create packages on Slackware and Arch Linux.<br><br>5) A change in version 3.2.5 broke Mac Filtration in some<br> cases. Result was:<br><br> Setting up MAC Filtration -- Phase 1...<br> iptables v1.3.6: policy match: invalid policy `--dir'<br> Try `iptables -h' or 'iptables --help' for more information.<br> ERROR: Command "/sbin/iptables -A eth1_fwd -s 0.0.0.0/0 -m state <br> --state NEW -m policy --pol --dir in -j eth1_mac" Failed<br><br>6) At VERBOSITY 1 and higher, the 'shorewall add' and 'shorewall<br> delete' commands generated a fractured message. The message<br> contents depended in the setting of IPSECFILE as follows:<br><br> IPSECFILE=ipsec<br><br> ipsec...<br><br> IPSECFILE=zones<br><br> IPSEC...<br><br> The messages have been corrected and are only produced at VERBOSITY<br> 2 and higher as follows:<br><br> IPSECFILE=ipsec<br><br> Processing /etc/shorewall/ipsec...<br><br> IPSECFILE=zones<br><br> Processing IPSEC...<br><br>7) Previously, when <action>:none appeared in a rule, the name of the<br> action chain created was preceded by "%" and might have a one- or<br> two-digit number appended. If both <action> and <action>:none<br> appeared, then two chains were created. This has been corrected<br> such that <action> and <action>:none are treated identically.<br><br>8) If SAVE_IPSETS=Yes in shorewall.conf, the "shorewall[-lite] save"<br> command produced error messages as follows:<br><br> Dynamic Rules Saved<br> Currently-running Configuration Saved to /var/lib/shorewall/restore<br> grep: /var/lib/shorewall/restore-base: No such file or directory<br> grep: /var/lib/shorewall/restore-base: No such file or directory<br> Current Ipset Contents Saved to<br> /var/lib/shorewall/restore-ipsets<br><br>9) If BRIDGING=No in shorewall.conf, then an attempt to define a zone<br> using ipsets fails as follows:<br><br> ERROR: BRIDGING=Yes is needed for this zone definition: z eth0:+iset<br><br>Other Changes in 3.2.6.<br><br>1) The "shorewall [re]load" command now supports a "-c" option.<br><br> Example:<br><br> shorewall reload -c gateway<br><br> When -c is given, Shorewall will capture the capabilities of the<br> remote system to a file named "capabilities" in the export<br> directory before compiling the configuration.<br><br> If the file "capabilities" does not currently exist in the <br> export directory then "-c" is automatically assumed.<br><br>2) If 0 (zero) is specified for the IN-BANDWIDTH in<br> /etc/shorewall/tcdevices then no ingress qdisc will be created for<br> the device.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-10-28 Shorewall 3.2.5<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Problems Corrected in 3.2.5<br><br>1) Entries such as the following in /etc/shorewall/masq generate a<br> run-time error:<br><br> eth0 eth1!192.168.1.12 206.124.146.176<br><br> Omitting the exclusion (!192.168.1.12) avoids the error.<br><br>2) Previously, the 'provider' portion of the packet mark was not being<br> cleared after routing for traffic that originates on the firewall<br> itself.<br><br>3) In prior releases, it was not possible to mark an outgoing packet<br> with a high mark (HIGH_ROUTE_MARKS=Yes) when the packet originated<br> on the firewall itself.<br><br>4) The detected capabilities were not displayed by 'shorewall dump'<br> when the effective VERBOSITY was less than 2.<br><br>Other changes in 3.2.5<br><br>1) For users whose kernel and iptables have Extended MARK Target<br> support, it is now possible to logically AND or OR a value into the<br> current packet mark by preceding the mark value (and optional mask)<br> with an ampersand ("&") or vertical bar ("|") respectively.<br><br> Example: To logically OR the value 4 into the mark value for<br> packets from 192.168.1.1:<br><br> #MARK SOURCE<br> |4 192.168.1.1<br><br>2) A new macro (macro.RDP) has been added for Microsoft Remote<br> Desktop. This macro was contributed by Tuomo Soini.<br><br>3) A new 'maclog' extension file has been added. This file is<br> processed just before logging based on the setting of<br> MACLIST_LOG_LEVEL is done. When the script is copyied at compile<br> time, the CHAIN variable will contain the name of the chain where<br> rules should be inserted. Remember that if you have specified<br> MACLIST_TABLE=mangle, then your run_iptables commands should<br> include "-t mangle".<br><br>4) Beginning with this release, Shorewall and Shorewall lite will<br> share the same change log and release notes.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-10-6 Shorewall 3.0.9<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Problems corrected in 3.0.9<br><br>1) When using a light-weight shell like ash or dash, "shorewall<br> [re]start" fails when using the built-in traffic shaper. The error<br> messages resemble these:<br><br> local: 3: eth0:: bad variable name<br> ERROR: Command "tc class add dev eth0 parent 1: classid 1:1 htb rate 800kbit mtu" Failed<br><br>2) The output formating of the 'hits' command under BusyBox 1.2.0 has<br> been corrected.<br><br>3) In prior versions, setting 'mss=' in /etc/shorewall/zones did not<br> affect traffic to/from the firewall zone. That has been corrected.<br><br>4) Previously, using IP address ranges in the accounting file could<br> cause non-fatal iptables errors during shorewall [re]start.<br><br>Other changes in 3.0.9<br><br>1) It is now possible to use the special value 'detect' in the ADDRESS<br> column of /etc/shorewall/masq. This allows you to specify SNAT (as<br> opposed to MASQUERADE) without having to know the ip address of the<br> external interface. Shorewall must be restarted each time that the<br> external address (the address of the interface named in the<br> INTERFACE column) changes.<br><br>2) Experimental optimization for PPP devices has been added to the<br> providers file. If you omit the GATEWAY column for a ppp device (or<br> enter "-" in the column) then Shorewall will generate routes<br> for the named INTERFACE that do not specify a gateway IP address<br> (the peer address will be assumed).<br><br>3) Normally, Shorewall tries to protect users from themselves by<br> preventing PREROUTING and OUTPUT tcrules from being applied to<br> packets that have been marked by the 'track' option in<br> /etc/shorewall/providers.<br><br> If you really know what you are doing and understand packet marking<br> thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and<br> Shorewall will not include these cautionary checks.<br><br>4) Previously, CLASSIFY tcrules were always processed out of the<br> POSTROUTING chain. Beginning with this release, they are processed<br> out of the POSTROUTING chain *except* when the SOURCE is<br> $FW[:<address>] in which case the rule is processed out of the<br> OUTPUT chain.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-09-27 Shorewall 3.2.4<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Shorewall Problems corrected in 3.2.4<br><br>1) Previously, the directory name in the command "shorewall start<br> <directory name>" was being dropped by "/sbin/shorewall".<br><br>2) Previous, when /usr/share/shorewall/xmodules had been copied to<br> /etc/shorewall/modules, Shorewall was not looking in the correct<br> directory for the "xt_..." modules. There are two parts to the fix:<br><br> - The /usr/share/shorewall/xmodules file has been removed. The<br> /usr/share/shorewall/modules file will now load all required<br> modules regardless of which kernel version you are running.<br> - The MODULESDIR option can now contain a colon-separated list of<br> directories to search for modules with the default being:<br><br> /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter:/lib/modules/$(uname -r)/kernel/net/netfilter<br><br>3) Rules in /etc/shorewall/tos which specify zones defined<br> using entries in /etc/shorewall/hosts applied to all traffic<br> to/from the zone interfaces (the bridge port, ipset or IP<br> address(es) in the zone definition were ignored).<br><br>4) Previously, 'shorewall-lite dump' did not report traffic shaping<br> information even if TC_ENABLED was set to Yes or Internal in the<br> shorewall.conf file used to compile the exported firewall script.<br><br> To correct this problem, the firewall script must be recompiled and<br> re-exported.<br><br>5) Previously, errors during the compile phase were not reflected in<br> the exit status of /sbin/shorewall. Thanks to Tuomo Soini for<br> finding and correcting this problem.<br><br>Other Shorewall changes in 3.2.4<br><br>1) Previously, scripts compiled for export (-e option) depended on<br> /usr/share/shorewall-lite/functions in order to run correctly. This<br> made it possible for a compiled script to be incompatible with the<br> version of Shorewall Lite installed on a firewall system.<br><br> Beginning with Shorewall 3.2.4, this dependency is removed such<br> that version incompatibility between Shorewall and Shorewall Lite<br> should not be a concern going forward.<br><br>2) Two new macros have been added, courtesy of Tuomo Soini<br><br> macro.Finger<br> macro.Telnets<br><br>3) The output of "shorewall show macros" has been enhanced to show<br> macros in each directory in the CONFIG_PATH.<br><br>Shorewall Lite problems corrected in 3.2.4<br><br>1) Previous, when /usr/share/shorewall-lite/xmodules had been copied to<br> /etc/shorewall-lite/modules, Shorewall was not looking in the correct<br> directory for the "xt_..." modules. There are two parts to the fix:<br><br> - The /usr/share/shorewall-lite/xmodules file has been removed. The<br> /usr/share/shorewall-lite/modules file will now load all required<br> modules regardless of which kernel version you are running.<br> - The MODULESDIR option can now contain a colon-separated list of<br> directories to search for modules with the default being:<br><br> /lib/modules/$(uname<br> -r)/kernel/net/ipv4/netfilter:/lib/modules/$(uname<br> -r)/kernel/net/netfilter<br><br> /usr/share/shorewall-lite/modules contains a *lot* of modules. If<br> you use module autoloading (which non-embedded Linux distributions<br> do), then you can improve your "shorewall [re]start" time by<br> trimming all but the helper modules from the file. To do that,<br> create the file /etc/shorewall-lite/modules with the following<br> entries:<br><br> loadmodule ip_conntrack_amanda<br> loadmodule ip_conntrack_ftp<br> loadmodule ip_conntrack_irc<br> loadmodule ip_conntrack_netbios_ns<br> loadmodule ip_conntrack_pptp<br> loadmodule ip_conntrack_tftp<br> loadmodule ip_nat_amanda<br> loadmodule ip_nat_ftp<br> loadmodule ip_nat_irc<br> loadmodule ip_nat_pptp<br> loadmodule ip_nat_snmp_basic<br> loadmodule ip_nat_tftp<br><br>Other Shorewall Lite changes in 3.2.4<br><br>None.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-08-26 Shorewall 3.2.3<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Shorewall Problems Corrected in 3.2.3<br><br> 1) A problem in 'install.sh' resulted in sandbox violations on<br> Gentoo and, when Shorewall is installed using an RPM, the problem<br> caused an incorrect copy of shorewall.conf to be installed in<br> /usr/share/shorewall/configfiles/.<br><br> 2) A typo in the functions file caused startup errors when the user's<br> distribution did not support a true mktemp program (such as<br> Bering Uclibc). Patch courtesy of Cédric Schieli.<br><br> 3) Several erroneous references to ip_addr_del() were made in<br> /var/lib/shorewall/compiler and in the code that it generates.<br><br> a) These should have been references to del_ip_addr()<br> b) One of the calls also had an incorrect parameter list.<br><br> 4) Previously, "shorewall check -e" would erroneously attempt to<br> detect interfaces configured for traffic shaping.<br><br> 5) SUBSYSLOCK functionality has been restored.<br><br> 6) In prior versions, setting 'mss=' in /etc/shorewall/zones did not<br> affect traffic to/from the firewall zone. That has been corrected.<br><br> 7) When /sbin/shorewall was run under BusyBox ash, shell errors would<br> occur if certain command options were given.<br><br> 8) Previously, the 'optional' provider option did not detect the case<br> where the interface was DOWN but still had a configured IP<br> address. Shorewall was detecting such interfaces as UP and later<br> 'ip replace route' commands would fail.<br><br> It should also be clarified that the 'optional' option is intended<br> to detect cases where a provider interface is in a state that would<br> cause 'shorewall [re]start' to fail; it is not intended to<br> determine whether communication is possible using the interface.<br><br> 9) Previously, the "shorewall add" command would fail with error<br> messages indicating that the commands "chain_exists" and<br> "verify_hosts_file" could not be found.<br><br> 10) Using earlier Shorewall versions, the following sequence of<br> commands produced inconsistant results:<br><br> a) shorewall [re] start<br> b) Modify /etc/shorewall/tcdevices and/or /etc/shorewall/tcclasses<br> c) shorewall refresh<br> d) shorewall save<br> e) shorewall restore (or reboot and shorewall start -f during boot<br> up)<br><br> After that series of commands, the state of traffic shaping was as<br> it was after step a) rather than as it was after step c). The fix<br> involved re-implementing 'shorewall refresh' as a compile/execute<br> procedure similar to [re]start. While the entire configuration is<br> recompiled, only ecn, blacklisting, tcrules and traffic control<br> will be updated in the running configuration.<br><br> 11) DNAT rules generated under DETECT_DNAT_IPADDRS=Yes may have been<br> incorrect with the result that the rules didn't work at all.<br><br> Other Shorewall changes in 3.2.3<br><br> 1) A 'shorewall export' command has been added.<br><br> shorewall export [ <directory1> ] [user@]<system>:[<directory2>]<br><br> If <directory1> is omitted, then the current working directory is<br> assumed.<br><br> Causes the shorewall configuration in <directory1> to be compiled<br> into a program called '<directory1>/firewall'. If compilation is<br> successful, the '<directory1>/firewall' script is copied via scp<br> to the specified <system>.<br><br> Example:<br><br> shorewall export admin@gateway:<br><br> This command would compile the configuration in the current working<br> directory then copy the 'firewall' (and 'firewall.conf') files to<br> admin's home directory on system 'gateway'.<br><br> 2) Normally, Shorewall tries to protect users from themselves by<br> preventing PREROUTING and OUTPUT tcrules from being applied to<br> packets that have been marked by the 'track' option in<br> /etc/shorewall/providers.<br><br> If you really know what you are doing and understand packet marking<br> thoroughly, you can set TC_EXPERT=Yes in shorewall.conf and<br> Shorewall will not include these cautionary checks.<br><br> 3) Previously, CLASSIFY tcrules were always processed out of the<br> POSTROUTING chain. Beginning with this release, they are processed<br> out of the POSTROUTING chain *except* when the SOURCE is<br> $FW[:<address>] in which case the rule is processed out of the<br> OUTPUT chain.<br><br> See the Migration Considerations section for further information.<br><br> 4) Previously, if you specified 'detectnets' on an interface with a<br> default route, Shorewall would ignore the default route with a<br> warning message. This could lead to systems that were inaccessible<br> from the net, even from systems listed in the 'routestopped' file.<br><br> Specifying 'detectnets' on an interface with a default route now<br> generates a fatal error.<br><br>Shorewall Lite problems corrected in 3.2.3<br><br>1) A typo in /usr/share/shorewall-lite/functions caused startup errors<br> on distributions like Bering Uclibc that don't have a true mktemp<br> utility.<br><br>Other Shorewall Lite changes in 3.2.3<br><br>None.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-08-10 Shorewall 3.2.2</span><br>
|
|
<span style="font-weight: bold;"></span>
|
|
<pre>Problems corrected in 3.0.8<br><br>1) If the 'upnp' interface option was specified on one or more<br> interfaces but no forwardUPnP rule was included, the following<br> diagnostic messages were issued:<br><br> WARNING:Missing forwardUPnP rule (required by 'upnp' interface option on<br> eth0)<br> ERROR: Fatal error in find_logactionchain<br><br> Given that the fatal error message is obscure if the first WARNING<br> isn't noticed, the ERROR message has been eliminated with the<br> result that Shorewall now starts but won't handle UPnP properly.<br><br>2) If BRIDGING=No in shorewall.conf, then an entry in<br> /etc/shorewall/hosts such as the following would result in an<br> obscure failure of an iptables command:<br><br> loc br0:eth0<br><br> Shorewall now detects this case and issues a more helpful error<br> message:<br><br> ERROR: BRIDGING=Yes is required for this zone definition: loc br0:eth0<br><br>3) Users of the Multi-ISP feature may experience this error during startup:<br><br> /usr/share/shorewall/firewall: line 1393: 20000 + (1 - 1) * 256 +<br> $rulenum : syntax error: operand expected (error token is<br> "$rulenum ")<br><br>4) A more useful diagnostic is now given when a command fails during<br> setup of traffic shaping.<br><br>5) Shorewall now checks to see if devices in /etc/shorewall/tcdevices<br> exist. If a device does not exist, a warning message is issued and<br> that device's entries in /etc/shorewall/tcclasses are ignored. This<br> applies to "shorewall start", "shorewall restart" and "shorewall<br> refresh".<br><br>6) It is now possible to exclude a single source MAC address using<br> !<MAC address>. Previously, a startup error occurred.<br><br>7) Shorewall would use the incorrect shell for compilation in the<br> following case:<br><br>8) Reporting of the "Mangle FORWARD Chain" capability was broken. While<br> Shorewall correctly detected and used the capability, the output of<br> "shorewall show capabilities" and "shorewall dump" showed the<br> capability as "Not Available".<br><br>9) Extension scripts for policy chains (chains with the word 'all' in<br> their name) were not being run previously.<br><br>-Tom</pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-07-24 End of support for Shorewall
|
|
2.4<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Support for Shorewall 2.4 has ended. As always, we will try to help you<br>with your problems but I personally will not spend any time reading old<br>code trying to solve your problem and I will not provide patches for any<br>bugs found in versions earlier than 3.0.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-07-21 Shorewall 3.2.1<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Problems Corrected in Shorewall 3.2.1:<br><br>1) The output formatting of the 'hits' command under BusyBox 1.2.0 has<br> been corrected.<br><br>2) Shorewall no longer requires extended MARK support to use the 'track'<br> provider option when HIGH_ROUTE_MARKS=No.<br><br>3) The output of the 'hits' command was previously scrambled if<br> /etc/services contained spaces as column delimiters rather than<br> tabs.<br><br>4) The /usr/share/shorewall/xmodules file was previously just a copy<br> of /usr/share/shorewall/modules.<br><br>5) The version number in the comments at the top of shorewall.conf has<br> been corrected.<br><br>6) The script generated when the -e option is given to the 'compile'<br> command is setting CONFIG_PATH to the value given in the remote<br> firewall's shorewall.conf processed at compile time. This is<br> generally incorrect and results in the inability to load any kernel<br> modules on the firewall during 'shorewall-lite [re]start'.<br><br>Problems Corrected in Shorewall Lite 3.2.1:<br><br>1) The output formatting of the 'hits' command under BusyBox 1.2.0 has<br> been corrected.<br><br>2) The output of the 'hits' command was previously scrambled if<br> /etc/services contained spaces as column delimiters rather than<br> tabs.<br><br>3) The /usr/share/shorewall-lite/xmodules file was previously just a<br> copy of /usr/share/shorewall-lite/modules.<br><br>4) The version number in the comments at the top of shorewall.conf has<br> been corrected.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-07-19 Shorewall bridge/firewall support
|
|
change upcoming<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre><tt>I regret to announce that Shorewall bridge/firewall support in its</tt><br><tt>current form (BRIDGING=Yes in shorewall.conf) is going away. I will</tt><br><tt>retain the code in Shorewall for the foreseeable future but users</tt><br><tt>migrating to new kernels coming out next year will find that their</tt><br><tt>current bridge configurations no longer work. Shorewall bridge/firewall</tt><br><tt>users upgrading to more immediate new kernel releases (possibly as early</tt><br><tt>as 2.6.18) will find Netfilter warning messages appearing in their</tt><br><tt>kernel log when Shorewall [re]starts.</tt><br><br><tt>The reason that this support is going away is that the underlying</tt><br><tt>Netfilter feature that BRIDGING=Yes depends on (physdev match) is being</tt><br><tt>reduced in scope to the point that it will no longer be possible to use</tt><br><tt>that feature for Shorewall zone definition. There is a significant list</tt><br><tt>of pending Netfilter bug reports than cannot be resolved so long as</tt><br><tt>'physdev match' works the way that it does today.</tt><br><br><tt>While 'physdev match' was a great idea in terms of the function that it</tt><br><tt>provides, it appears impossible to implement that function without</tt><br><tt>breaking other parts of the greater Linux IP stack; in short, 'physdev</tt><br><tt>match' in its current form should never have been released in the first</tt><br><tt>place.</tt><br><br><tt>So -- what can current Shorewall bridge/firewall users do? </tt><br><tt>-----------------------------------------------------------------------</tt><br><tt>a) Configure Shorewall as if you have a simple bridge</tt><br><tt>(<a href="http://www.shorewall.net/SimpleBridge.html">http://www.shorewall.net/SimpleBridge.html</a>) and use ebtables to filter</tt><br><tt>traffic in and out of the individual bridge ports.</tt><br><br><tt>b) Configure Shorewall so that you specifically enumerate the IP</tt><br><tt>addresses of the hosts connected to all but one of the bridge ports.</tt><br><br><tt>Example where br0 connects to 192.168.1.0/24:</tt><br><br><tt>/etc/shorewall/shorewall.conf</tt><br><br><tt>BRIDGING=<doesn't matter></tt><br><br><tt>/etc/shorewall/zones</tt><br><br><tt>z1 ipv4</tt><br><tt>z2 ipv4</tt><br><br><tt>/etc/shorewall/interfaces</tt><br><br><tt>- br0 detect routeback</tt><br><br><tt>/etc/shorewall/hosts:</tt><br><br><tt>z1 br0:192.168.1.1-192.168.1.15,192.168.1.18,...</tt><br><tt>z2 br0:192.168.1.0/24</tt><br><br><tt>In other words, explicitly specify the hosts in the first zone listed</tt><br><tt>in /etc/shorewall/zones (z1 in the above example) then simply specify</tt><br><tt>the entire network for the second zone. If the second zone contains your</tt><br><tt>default gateway, then you would enter 0.0.0.0/0 rather than</tt><br><tt>192.168.1.0/24.</tt><br><br><tt>I will expand these instructions into an article on the web site just as</tt><br><tt>soon as I find the time.</tt><br><br><tt>c) If you have ipset support, you can take the same approach as in b)</tt><br><tt>above but define 'z1' using one or more ipsets rather than with an</tt><br><tt>explicit lists of network/host IP addresses. That will generally result</tt><br><tt>in a smaller ruleset.</tt><br><tt>-----------------------------------------------------------------------</tt><br><tt>I realize that the options available to you are more cumbersome to</tt><br><tt>configure and maintain than what you have today but at the moment, I see</tt><br><tt>no alternatives. I will however continue to ponder the problem, and if I</tt><br><tt>come up with something better I will let you know.</tt><br><br><tt>-Tom</tt></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-07-11 Shorewall 3.2.0<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>New Features:<br><br>1) Shorewall has always been very noisy (lots of messages). No longer.<br><br> You set the default level of verbosity using the VERBOSITY option in<br> shorewall.conf. If you don't set it (as would be the case if you use your<br> old shorewall.conf file) then VERBOSITY defaults to a value of 2 which<br> results in behavior compatible with previous Shorewall versions.<br> A value of 1 suppresses some of the output (like the old -q option did)<br> while a value of 0 makes Shorewall almost silent. A value of -1<br> suppresses all output except warning and error messages.<br><br> The value specified in the 3.2 shorewall.conf is 1. So you can make<br> Shorewall as verbose as previously using a single -v and you can make it<br> almost silent by using a single -q.<br><br> If VERBOSITY is set at 2, you can still make a command nearly<br> silent by using two "q"s (e.g., shorewall -qq restart).<br><br> In summary, each "q" subtracts one from VERBOSITY while each "v" adds one<br> to VERBOSITY.<br><br> The "shorewall show log", "shorewall logwatch" and "shorewall dump"<br> commands require VERBOSITY to be greater than or equal to 3 to<br> display MAC addresses.This is consistent with the previous<br> implementation which required a single -v to enable MAC display but<br> means that if you set VERBOSITY=0 in shorewall.conf, then you will<br> need to include -vvv in commands that display log records in order<br> to have MACs displayed.<br><br> To make the display of MAC addresses less cumbersome, a '-m' option has<br> been added to the "show" and logwatch commands:<br><br> shorewall show -m log<br> shorewall logwatch -m<br><br>2) A new 'shorewall compile' command has been added.<br><br> shorewall compile [ -e ] [ <config directory> ] <script file><br><br> where:<br><br> -e Allows the generated script to run<br> on a system with Shorewall Lite installed.<br> Generates an error if the configuration uses<br> an option that would prevent the generated<br> script from running on a system other than<br> where the 'compile' command is running (see<br> additional consideration a) below).<br><br> <config directory> Is an optional directory to be searched for<br> configuration files prior to those listed<br> in CONFIG_DIR in<br> /etc/shorewall/shorewall.conf.<br><br> <script file> Is the name of the output file.<br><br> The 'compile' command processes the configuration and generates a<br> script file which may then be executed to configure the firewall.<br><br> The generated script supports the following commands:<br><br> start - starts the firewall<br> stop - stops the firewall<br> clear - clears the firewall (removes all iptables rules)<br> restart - restarts the firewall<br> status - displays the firewall status<br> version - displays the version of shorewall used to create the<br> script<br><br> The generated script contains error checking and will terminate if an<br> important command fails. Before terminating:<br><br> a) The script will check for the existence of the restore script<br> specified by the RESTOREFILE variable in shorewall.conf. If that<br> restore script exists, it is executed.<br><br> b) If the restore script doesn't exist but Shorewall appears to be<br> installed on the system, the equivalent of an<br> "/sbin/shorewall stop" command is executed.<br><br> Some additional considerations:<br><br> a) When you run 'compile' on one system and then run the generated script<br> on another system under Shorewall Lite, there are certain limitations.<br><br> 1) A compatible version of Shorewall Lite must be running on the remote<br> system. Going forward, the goal is that any minor version of<br> the current major version will be compatible. So if the<br> program is compiled using Shorewall 3.2.x, any 3.2.y version<br> or 3.p.q version (where p > 2) of Shorewall Lite will be compatible.<br> 2) The 'detectnets' interface option is not allowed.<br> 3) DYNAMIC_ZONES=Yes is not allowed.<br> 4) You must supply the file /etc/shorewall/capabilities to provide<br> the compiler with knowledge of the capabilities of the system<br> where the script is to be run. See below.<br> 5) If your /etc/shorewall/params file contains code other than simple<br> assignment statements with contant values, then you should move<br> that code to /etc/shorewall/init. That way, the code will be<br> executed on the target system when the compiled script is run and<br> not on the local system at compile time.<br><br> b) If you run the "shorewall compile" or "shorewall check" commands under<br> a user other than 'root', then you must supply<br> /etc/shorewall/capabilities.<br><br> c) To aid in building /etc/shorewall/capabilities, a 'shorecap' program<br> is provided in the Shorewall Lite package and is installed in<br> /usr/share/shorewall-lite/shorecap when you install Shorewall Lite.<br><br> For instructions about running shorecap, see the comments at the<br> top of the program file (it's a simple shell script).<br><br> The "shorewall start" and "shorewall restart" commands have been<br> rewritten to use compilation. They both compile a temporary program<br> then run it. This results in a slightly longer elapsed time than the<br> similar commands required under earlier versions of Shorewall but new<br> connections are blocked for a much smaller percentage of that time.<br><br> If an error is found during the compilation phase, /sbin/shorewall<br> terminates and the Shorewall state is unchanged.<br><br> Under Shorewall 3.1.5, "shorewall restart" takes roughly 16.5 seconds<br> on my firewall:<br><br> real 0m16.599s<br> user 0m6.292s<br> sys 0m9.885s<br><br> Of the elapsed 16.5 seconds, new connections are disabled less than<br> 3.5 seconds. Here are some numbers for comparison:<br><br> A) shorewall restart (Shorewall 3.0.4)<br><br> real 0m17.540s<br> user 0m5.956s<br> sys 0m10.737s<br><br> B) ./foo restart # foo created using "shorewall compile"<br><br> real 0m3.297s<br> user 0m1.444s<br> sys 0m1.728s<br><br> C) shorewall restore (Shorewall 3.0.4) # Restores from file generated by<br> # "shorewall save"<br><br> real 0m1.164s<br> user 0m0.556s<br> sys 0m0.608s<br><br> D) shorewall restore (shorewall 3.1.5)<br><br> real 0m1.637s<br> user 0m0.728s<br> sys 0m0.584s<br><br> The time difference between B and C reflects the difference between<br> "iptables-restore" and multiple executions of "iptables". The time<br> difference between C and D results from the fact that the "restore"<br> command in Shorewall 3.1 runs the compiled program in a way that<br> turns all iptables commands into no-ops then invokes<br> iptables-restore. The system is a 1.4Ghz Celeron with 512MB RAM.<br><br> As a final part of this change, the "check" command now compiles the<br> current configuration and writes the compiled output to /dev/null. So<br> "check" performs all of the same validation that compile does. Note that<br> there is still no guarantee that the generated script won't encounter<br> run-time errors.<br><br>2) The /etc/shorewall/maclist file has a new column layout. The first column<br> is now DISPOSITION. This column determines what to do with matching<br> packets and can have the value ACCEPT or DROP (if MACLIST_TABLE=filter, it<br> can also contain REJECT). This change is upward compatible so your existing<br> maclist file can still be used.<br><br> ACCEPT, DROP and REJECT may be optionally followed by a log level to<br> cause the packet to be logged.<br><br>4) In macro files, you can now use the reserved words SOURCE and DEST<br> in the columns of the same names. When Shorewall expands the<br> macro, it will substitute the SOURCE from the macro invocation for<br> SOURCE and the DEST from the invocation for DEST. This allows you<br> to write macros that act in both directions (from source to destination<br> and from destination to source).<br><br> Example:<br><br> macro.FOO:<br><br> PARAM SOURCE DEST udp 500<br> PARAM DEST SOURCE udp 500<br><br> /etc/shorewall/rules:<br><br> FOO/ACCEPT fw net<br><br> Resulting rules:<br><br> ACCEPT fw net udp 500<br> ACCEPT net fw udp 500<br><br> This new feature has been used to implement the SMBBI macro.<br> SMBBI is the same as the SMB macro with the exception that<br> it passes SMB traffic in both directions whereas SMB only<br> passes that traffic in one direction.<br><br>5) In the /etc/shorewall/rules file and in actions, you may now specify<br> 'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to 'tcp' but also<br> requires that the SYN flag is set and the RST, FIN and ACK flags be<br> off ("--syn" is added to the iptables rule).<br><br> As part of this change, Shorewall no longer adds the "--syn" option<br> to TCP rules that specify QUEUE as their target.<br><br>6) /sbin/shorewall now supports a "-t" option that causes all progress<br> messages to be timestamped.<br><br> Example (VERBOSITY=0 in shorewall.conf):<br><br> gateway:/etc/shorewall # shorewall -t restart<br> 07:08:51 Compiling...<br> 07:09:05 Shorewall configuration compiled to /var/lib/shorewall/.restart<br> 07:09:05 Restarting Shorewall....<br> 07:09:08 done.<br> gateway:/etc/shorewall #<br><br>7) A 'refreshed' extension script has been added -- it is executed after<br> "shorewall refresh" has finished.<br><br>8) Two new dynamic blacklisting commands have been added:<br><br> logdrop -- like 'drop' but causes the dropped packets to be logged.<br><br> logreject -- like 'reject' but causes the rejected packets to be<br> logged.<br><br> Packets are logged at the BLACKLIST_LOGLEVEL if one was specified at the<br> last "shorewall [re]start"; otherwise, they are logged at the 'info'<br> log level.<br><br>9) A new IMPLICIT_CONTINUE option has been added to shorewall.conf. When<br> this option is set to "Yes", it causes subzones to be treated differently<br> with respect to policies.<br><br> Subzones are defined by following their name with ":" and a list of parent<br> zones (in /etc/shorewall/zones). Normally, you want to have a set of<br> special rules for the subzone and if a connection doesn't match any of<br> those subzone-specific rules then you want the parent zone rules and<br> policies to be applied. With IMPLICIT_CONTINUE=Yes, that happens<br> automatically.<br><br> If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set, then<br> subzones are not subject to this special treatment.<br><br> With IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden<br> by including an explicit policy (one that does not specify "all" in either<br> the SOURCE or the DEST columns).<br><br> Example:<br><br> /etc/shorewall/zones:<br><br> prnt ipv4<br> chld:prnt ipv4<br><br> Traffic to/from the 'chld' zone will first pass through the applicable<br> 'chld' rules and if none of those rules match then it will be passed through<br> the appropriate 'prnt' rules. If the connection request does not match<br> any of the 'prnt' rules then the relevant 'prnt' policy is applied.<br><br> If you want the fw->chld policy to be ACCEPT, simply add this entry to<br> /etc/shorewall/policy:<br><br> $FW chld ACCEPT<br><br> Traffic from all other zones to 'chld' will be subject to the implicit<br> CONTINUE policy.<br><br>10) Shorewall now includes support for explicit routing rules when the<br> /etc/shorewall/providers file is used. A new file,<br> /etc/shorewall/route_rules can be used to add routing rules based on<br> packet source and/or destination.<br><br> The file has the following columns:<br><br> SOURCE(optonal) An ip address (network or host) that<br> matches the source IP address in a packet.<br> May also be specified as an interface<br> name optionally followed by ":" and an<br> address. If the define 'lo' is specified,<br> the packet must originate from the firewall<br> itself.<br><br> DEST(optional) An ip address (network or host) that<br> matches the destination IP address in a packet.<br><br> If you choose to omit either SOURCE or DEST,<br> place "-" in the column. Note that you<br> may not omit both SOURCE and DEST.<br><br> PROVIDER The provider to route the traffic through.<br> May be expressed either as the provider name<br> or the provider number. You may also specify<br> the 'main' routing table here, either by<br> name or by number (254).<br><br> PRIORITY<br> The rule's priority which determines the order<br> in which the rules are processed.<br><br> 1000-1999 Before Shorewall-generated<br> 'MARK' rules<br><br> 11000- 11999 After 'MARK' rules but before<br> Shorewall-generated rules for<br> provider interfaces.<br><br> 26000-26999 After provider interface rules but<br> before 'default' rule.<br><br> Rules with equal priority are applied in<br> the order in which they appear in the file.<br><br> Example 1: You want all traffic coming in on eth1 to be routed to the ISP1<br> provider:<br><br> #PROVIDER PRIORITY SOURCE DEST<br> ISP1 1000 eth1<br><br> Example 2: You use OpenVPN (routed setup /tunX) in combination with multiple<br> providers. In this case you have to set up a rule to ensure that<br> the OpenVPN traffic is routed back through the tunX interface(s)<br> rather than through any of the providers. 10.8.0.0/24 is the<br> subnet choosen in your OpenVPN configuration (server 10.8.0.0<br> 255.255.255.0)<br><br> #SOURCE DEST PROVIDER PRIORITY<br> - 10.8.0.0/24 main 1000<br><br>11) Prior to now, it has not been possible to use connection marking in<br> /etc/shorewall/tcrules if you have a multi-ISP configuration that uses the<br> 'track' option.<br><br> Beginning with this release, you may now set HIGH_ROUTE_MARKS=Yes in<br> shorewall.conf to effectively divide the packet mark and connection mark<br> into two 8-byte mark fields.<br><br> When you do this:<br><br> a) The MARK field in the providers file must have a value that is<br> less than 65536 and that is a multiple of 256 (using hex<br> representation, the values are 0x0100-0xFF00 with the low-order<br> 8 bits being zero).<br><br> b) You may only set those mark values in the PREROUTING chain.<br><br> c) Marks used for traffic shaping must still be in the range of 1-255<br> and may still not be set in the PREROUTING chain.<br><br> d) When you SAVE or RESTORE in tcrules, only the TC mark value is<br> saved or restored. Shorewall handles saving and restoring the<br> routing (provider) marks.<br><br>12) A TOS column has been added to /etc/shorewall/tcrules. This allows marking<br> based on the contents of the TOS field in the packet header.<br><br>13) Beginning with this release, the way in which packet marking in the<br> PREROUTING chain interracts with the 'track' option in /etc/shorewall/providers<br> has changed in two ways:<br><br> a) Packets *arriving* on a tracked interface are now passed to the PREROUTING<br> marking chain so that they may be marked with a mark other than the<br> 'track' mark (the connection still retains the 'track' mark).<br><br> b) When HIGH_ROUTE_MARKS=Yes, you can still clear the mark on packets<br> in the PREROUTING chain (i.e., you can specify a mark value of zero).<br><br>14) Shorewall will now attempt to detect the MTU of devices listed in<br> /etc/shorewall/tcdevices and will use the detected MTU in setting<br> up traffic shaping.<br><br>15) In /etc/shorewall/rules, the values "all-" and "all+-" may now be<br> used for zone names. "all-" means "All zones except the firewall";<br> "all+-" means "All zones except the firewall" and intra-zone<br> traffic is included.<br><br>16) Kernel version 2.6.16 introduces 'xtables', a new common packet<br> filtering and connection tracking facility that supports both IPv4<br> and IPv6. Because a different set of kernel modules must be loaded<br> for xtables, Shorewall now includes two 'modules' files:<br><br> a) /usr/share/shorewall/modules -- the former<br> /etc/shorewall/modules<br><br> b) /usr/share/shorewall/xmodules -- a new file that support<br> xtables.<br><br> If you wish to use the new file, then simply execute this command:<br><br> cp -f /usr/share/shorewall/xmodules /etc/shorewall/modules<br><br>17) Shorewall now checks to see if devices in /etc/shorewall/tcdevices<br> exist. If a device does not exist, a warning message is issued and<br> that device's entries in /etc/shorewall/tcclasses are ignored. This<br> applies to "shorewall start", "shorewall restart" and "shorewall<br> refresh".<br><br>18) "load" and "reload" commands have been added. These commands allow<br> a non-root user with ssh access to a remote system running<br> Shorewall Lite to compile a firewall script on the local system and<br> to install that script on the remote system.<br><br> Syntax is:<br><br> shorewall [re]load [ <directory> ] <system><br><br> If <directory> is omitted, the current working directory is<br> assumed.<br><br> The command is equivalent to:<br><br> /sbin/shorewall compile -e <directory> firewall &&\<br> scp firewall root@<system>:/var/lib/shorewall-lite/ &&\<br> ssh root@<system> '/sbin/shorewall-lite [re]start' # Note 1<br><br> In other words, the configuration in the specified (or defaulted)<br> directory is compiled to a file called firewall in that<br> directory. If compilation succeeds, then 'firewall' is copied to the<br> (usually remote) <system> using scp. If the copy succeeds,<br> Shorewall Lite on <system> is started or restarted via ssh (<br> load causes Shorewall Lite to be started and 'reload' causes<br> Shorewall Lite to be re-started)<br><br> Note 1: In Shorewall Lite 3.2.0 RC4, the 'firewall' script has moved<br> from /usr/share/shorewall-lite/ to /var/lib/shorewall-lite in<br> packages from shorewall.net. The package maintainers for the<br> various distributions are free to choose the directory where the<br> script will be stored under their distribution by altering the<br> value of LITEDIR in /usr/share/shorewall/configpath. You can run the<br> "shorewall show config" command to see how your distribution<br> defines LITEDIR.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-06-21 Shorewall 3.0.8<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Problems corrected in 3.0.8<br><br>1) If the 'upnp' interface option was specified on one or more<br> interfaces but no forwardUPnP rule was included, the following<br> diagnostic messages were issued:<br><br> WARNING:Missing forwardUPnP rule (required by 'upnp' interface option on<br> eth0)<br> ERROR: Fatal error in find_logactionchain<br><br> Given that the fatal error message is obscure if the first WARNING<br> isn't noticed, the ERROR message has been eliminated with the<br> result that Shorewall now starts but won't handle UPnP properly.<br><br>2) If BRIDGING=No in shorewall.conf, then an entry in<br> /etc/shorewall/hosts such as the following would result in an<br> obscure failure of an iptables command:<br><br> loc br0:eth0<br><br> Shorewall now detects this case and issues a more helpful error<br> message:<br><br> ERROR: BRIDGING=Yes is required for this zone definition: loc br0:eth0<br><br>3) Users of the Multi-ISP feature may experience this error during startup:<br><br> /usr/share/shorewall/firewall: line 1393: 20000 + (1 - 1) * 256 +<br> $rulenum : syntax error: operand expected (error token is<br> "$rulenum ")<br><br>4) A more useful diagnostic is now given when a command fails during<br> setup of traffic shaping.<br><br>5) Shorewall now checks to see if devices in /etc/shorewall/tcdevices<br> exist. If a device does not exist, a warning message is issued and<br> that device's entries in /etc/shorewall/tcclasses are ignored. This<br> applies to "shorewall start", "shorewall restart" and "shorewall<br> refresh".<br><br>6) It is now possible to exclude a single source MAC address using<br> !<MAC address>. Previously, a startup error occurred.<br><br>7) Shorewall would use the incorrect shell for compilation in the<br> following case:<br><br>8) Reporting of the "Mangle FORWARD Chain" capability was broken. While<br> Shorewall correctly detected and used the capability, the output of<br> "shorewall show capabilities" and "shorewall dump" showed the<br> capability as "Not Available".<br><br>9) Extension scripts for policy chains (chains with the word 'all' in<br> their name) were not being run previously.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-05-27 Shorewall 2.4.9<br>
|
|
</span><span style="font-weight: bold;"></span>
|
|
<pre>Problems corrected in 2.4.9<br><br>1) Updated the bogons file to reflect recent IANA allocations.<br><br>2) If you use SAME or SAME:nodst in the ADDRESS column of /etc/shorewall/masq and<br> if you set ADD_SNAT_ALIASES=Yes in shorewall.conf, then "shorewall start" will<br> fail with the error 'Error: an inet prefix is expected rather than "SAME".'.<br><br>3) It is now possible to exclude a single source MAC address using<br> !<MAC address>. Previously, a startup error occurred.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-05-06 Shorewall 3.0.7<br>
|
|
</span>
|
|
<pre>Problems corrected in 3.0.7<br><br>1) Previously, if your kernel did not supply the mangle table FORWARD chain<br> then "shorewall [re]start" would fail. Now, if your mangle table does<br> not supply this chain Shorewall will avoid using either that chain or<br> the mangle table POSTROUTING chain. This change is strictly to stop Shorewall<br> from blowing up during [re]start on very old kernels (such as 2.4.17<br> running on a PS2); if your kernel does not support these chains and you<br> try to mark packets in either of them using entries in<br> /etc/shorewall/tcrules, [re]start will fail.<br><br>2) Previously, if there were more than 10 IP addresses on a multi-ISP interface,<br> some of the routing rules generated by Shorewall were placed after the<br> default rule which resulted in them not being recognized.<br><br>3) When install.sh is used to install on a Debian or Ubuntu system, the<br> SUBSYSLOCK option in shorewall.conf was not being cleared.<br> It will now be cleared, provided that Perl is installed on the system.<br><br>4) When exclusion lists appeared in the /etc/shorewall/tcrules file, the<br> resulting 'exclusion chains' (whose names begin with 'excl_') were not<br> deleted as part of 'shorewall [re]start'. This meant that 'refresh'<br> would fail, either the first or second time that it was done since<br> the last 'shorewall [re]start'.<br><br>Other changes in 3.0.7<br><br>None.<br></pre>
|
|
<!-- Shorewall Release 3.0.5 ENDS-->
|
|
<!-- Shorewall moving to Subversion -->
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-03-28 Shorewall moved to Subversion <br>
|
|
</span>
|
|
<pre> Effectively today, Shorewall source code repository was migrated to Subversion SCM.<br><br>Please read <a href="https://sourceforge.net/svn/?group_id=22587">https://sourceforge.net/svn/?group_id=22587 </a>
|
|
and <a href="http://www.shorewall.net/download.htm#SVN"> http://www.shorewall.net/download.htm#SVN </a>
|
|
for more information.</pre>
|
|
<!-- Moving to Subversion ENDS -->
|
|
<!-- Shorewall Release 3.0.5 -->
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-03-28 Shorewall 3.0.6<br>
|
|
</span>
|
|
<pre>Problems corrected in 3.0.6<br><br>1) A typo in the output of "help drop" has been corrected.<br><br>2) Previously, 'shorewall start' would fail in the presence of a network<br> interface named 'inet'.<br><br>3) A shell syntax error was reported when duplicate policies appeared in<br> /etc/shorewall/policy.<br><br>4) The iptable_nat and iptable_mangle modules were previously omitted<br> from /etc/shorewall/modules.<br><br>5) If you use SAME or SAME:nodst in the ADDRESS column of /etc/shorewall/masq <br> and if you set ADD_SNAT_ALIASES=Yes in shorewall.conf, then "shorewall <br> start" will fail with the error 'Error: an inet prefix is expected rather <br> than "SAME".'.<br><br>6) Previously, the 'routeback' option was ignored in an entry in the<br> /etc/shorewall/hosts file that referred to a (set of) bridge port(s).<br><br> Example:<br><br> dmz xenbr0:vif+ routeback<br><br>Other changes in 3.0.6<br><br>1) A 'refreshed' extension script has been added -- it is executed after<br> "shorewall refresh" has finished.<br></pre>
|
|
<!-- Shorewall Release 3.0.5 ENDS-->
|
|
<!-- Shorewall Release 3.0.5 -->
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-02-10 Shorewall 3.0.5<br>
|
|
</span>
|
|
<pre>Problems corrected in Shorewall 3.0.5<br><br>1) Previously, if /etc/shorewall/ipsets existed, it was run when Shorewall starts<br> but not when Shorewall was restored.<br><br>2) When using the NETKEY IPSEC implementation in kernel 2.6 but without the<br> policy match patch and the Netfilter/IPSEC patches, previously an<br> entry in /etc/shorewall/tunnels was not sufficient in cases where:<br><br> a) gw<->gw traffic was encrypted<br> b) The gw<->gw policy through the tunnel was not ACCEPT<br><br> Thanks to Tuomo Soini, this has been corrected. By simply including the<br> remote VPN zone in the GATEWAY ZONE column for the tunnel's entry, no<br> additional rules are required.<br><br>3) Extra blank output lines are no longer produced by install.sh (patch<br> courtesy of Tuomo Soini).<br><br>4) TCP packets sent to QUEUE by rules in the ESTABLISHED section of the<br> rules file previously didn't work (they had the "--syn" parameter<br> added to them which resulted in a rule that no traffic would match).<br><br> WARNING: If you use the QUEUE target from an action, Shorewall will<br> still insert --syn if the protocol is tcp. So you don't want to<br> invoke such an action from the ESTABLISHED section of the rules<br> file.<br><br>5) The description of the SOURCE column in /etc/shorewall/rules has been<br> improved (patch courtesy of Ed Suominen).<br><br>6) The 'allow', 'drop' and 'reject' commands no longer produce iptables<br> errors when executed while Shorewall is not started.<br><br>7) The spelling of "maximize-throughput" has been corrected in the code<br> that implements tcclasses parsing. Patch courtesy of Paul Traina.<br><br>8) Shorewall now generates the correct match for devices in<br> /etc/shorewall/tcdevices that are actually bridge ports.<br><br>New Features in Shorewall 3.0.5<br><br>1) The facilities available for dealing with the TOS field in<br> /etc/shorewall/tcclasses has been expended. The OPTIONS field is now may<br> contain a comma-separates list of the following:<br><br> tos=0x<value>[/0x<mask>] (mask defaults to 0xff)<br> - this lets you define a classifier<br> for the given <value>/<mask> combination<br> of the IP packet's TOS/Precedence/DiffSrv<br> octet (aka the TOS byte). Please note,<br> classifiers override all mark settings,<br> so if you define a classifer for a class,<br> all traffic having that mark will go in it<br> regardless of any mark set on the packet<br> by a firewall/mangle filter.<br><br> NOTE: multiple tos= statements may be<br> applied per class and per interface, but<br> a given value/mask pair is valid for only<br> ONE class per interface.<br><br> tos-<tosname> - aliases for the following TOS octet<br> value and mask encodings. TOS encodings<br> of the "TOS byte" have been deprecated in<br> favor of diffserve classes, but programs<br> like ssh, rlogin, and ftp still use them.<br><br> tos-minimize-delay 0x10/0x10<br> tos-maximize-throughput 0x08/0x08<br> tos-maximize-reliability 0x04/0x04<br> tos-minimize-cost 0x02/0x02<br> tos-normal-service 0x00/0x1e<br><br> tcp-ack - defined causes an tc filter to<br> be created that puts all tcp ack<br> packets on that interface that have<br> an size of <=64 Bytes to go in this<br> class. This is useful for speeding up<br> downloads. Please note that the size<br> of the ack packets is limited to 64<br> bytes as some applications (p2p for<br> example) use to make every packet an<br> ack packet which would cause them<br> all into here. We want only packets<br> WITHOUT payload to match, so the size<br> limit.<br><br> NOTE: This option is only valid for<br> ONE class per interface.<br><br> Note that the semantics of 'tos-<tosname>' have changed slightly. Previously,<br> these were tested using a mask of 0xff (example: tos-minimize-delay was<br> equivalent to 0x10/0xff). Now each bit is tested individually.<br><br> This enhancement is courtesy of Paul Traina.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2006-01-05 Shorewall 3.0.4<br>
|
|
</span>
|
|
<pre>Problems Corrected in 3.0.4<br><br>1) The shorewall.conf file is once again "console friendly". Patch is<br> courtesy of Tuomo Soini.<br><br>2) A potential security hole has been closed. Previously, Shorewall ACCEPTed<br> all traffic from a bridge port that was sent back out on the same port. If<br> the port was described in /etc/shorewall/hosts using the wildcard "+" (eg,<br> xenbr0:vif+), this could lead to traffic being passed in variance with the<br> supplied policies and rules.<br><br>3) Previously, an intra-zone policy of NONE would cause a startup error. That<br> problem has been corrected.<br><br>4) When RETAIN_ALIASES=Yes, the script produced by "shorewall save" did not<br> add the retained aliases. This means that the following sequence of<br> events resulted in missing aliases:<br><br> shorewall start<br> shorewall restart<br> shorewall save<br> reboot<br> shorewall -f start (which is the default during boot up)<br><br>5) When a 2.x standard action is invoked with a log level (example<br> "AllowPing:info"), logging does not occur.<br><br>New Features in 3.0.4<br><br>1) By popular demand, the 'Limit' action described at<br> http://www1.shorewall.net/PortKnocking.html#Limit has been made a standard<br> action. Limit requires 'recent match' support in your kernel and iptables.<br><br>2) DISABLE_IPV6 no longer disabled local (loopback) IPV6 traffic. This<br> change is reported to improve Java startup time on some distributions.<br><br>3) Shorewall now contains support for wildcard ports. In<br> /etc/shorewall/hosts, you may specify the port name with trailing "+" then <br> use specific port names in rules.<br><br> Example:<br><br> /etc/shorewall/hosts<br><br> vpn br0:tap+<br><br> /etc/shorewall/rules<br><br> DROP vpn:tap0 vpn:tap1 udp 9999<br><br>4) For the benefit of those who run Shorewall on distributions that don't <br> autoload kernel modules, /etc/shorewall/modules now contains load commands <br> for a wide range of Netfilter modules.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2005-12-13 Shorewall 3.0.3<br>
|
|
</span>
|
|
<pre>Problems Corrected in 3.0.3<br><br>1) The comments in the /etc/shorewall/shorewall.conf and<br> /etc/shorewall/hosts files have been changed to clarify when<br> BRIDGING=Yes is required when dealing with bridges.<br><br>2) Thanks to Tuomo Soini, formatting of the comments in the tcdevices<br> and tcclasses files has been cleaned up.<br><br>3) Specifying 'trace' on the 'safe-start' and 'safe-restart' command no<br> longer fails.<br><br>4) The output of "shorewall help restore" has been corrected. It previously<br> printed incorrect syntax for that command.<br><br>5) The README.txt file in the tarball was stale and contained incorrect<br> information. It has been corrected.<br><br>6) The shorewall.conf default setting of CLEAR_TC was previously "No". Given<br> that the default setting of TC_ENABLED is "Internal", the setting of<br> CLEAR_TC has been changed to the more appropriate value of "Yes".<br><br>7) Specifying an interface name in the SOURCE column of /etc/shorewall/tcrules<br> resulted in a startup error.<br><br>8) When the 'install.sh' script is used on Debian, it now creates<br> /var/log/shorewall-init.log. And if perl is installed on the system then<br> STARTUP_ENABLED=Yes is specified in shorewall.conf (the user must still<br> set startup=1 in /etc/default/shorewall).<br><br>New Features in 3.0.3 <br>
|
|
|
|
1) A "shorewall show macros" command has been added. This command displays
|
|
a list of the standard macros along with a brief description of each.
|
|
|
|
2) The '-q' option is now supported with 'safe-start' and 'safe-restart'.
|
|
|
|
3) The value "-" is now allowed in the ADDRESS/SUBNET column of
|
|
/etc/shorewall/blacklist. That value is equivalent to specifying
|
|
0.0.0.0/0 in that column.
|
|
|
|
4) The output of "shorewall show tc" and "shorewall show classifiers" is
|
|
now included in the output from "shorewall dump". This will aid us in
|
|
analyzing traffic shaping problems.
|
|
|
|
5) You can now specify 'none' in the COPY column of /etc/shorewall/providers
|
|
to signal that you want Shorewall to only copy routes through the interface
|
|
listed in the INTERFACE column.
|
|
|
|
Note: This works on older versions of Shorewall as well. It is
|
|
now documented.
|
|
|
|
6) An 'ipdecimal' command has been added to /sbin/shorewall. This command
|
|
converts between dot-quad and decimal.
|
|
|
|
Example:
|
|
|
|
gateway:/etc/openvpn# shorewall ipdecimal 192.168.1.4
|
|
3232235780
|
|
gateway:/etc/openvpn# shorewall ipdecimal 3232235780
|
|
192.168.1.4
|
|
gateway:/etc/openvpn#
|
|
|
|
7) /etc/init.d/shorewall now supports a 'reload' command which is
|
|
synonymous with the 'restart' command.</pre>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2005-12-12 Shorewall 2.4.7</span><br>
|
|
<br>
|
|
Problems Corrected in 2.4.7<br>
|
|
<br>
|
|
1) When MACLIST_TABLE=mangle and an interface is enabled for DHCP
|
|
(the<br>
|
|
'dhcp' option is specified in /etc/shorewall/interfaces)
|
|
then broadcasts<br>
|
|
on UDP port 67 to address 255.255.255.255 from address
|
|
0.0.0.0 were being<br>
|
|
dropped and logged. While this did not prevent the client
|
|
from acquiring<br>
|
|
an IP address, it could result in lots of log messages.<br>
|
|
<br>
|
|
2) Entries for openvpn tunnels (including openvpnclient and<br>
|
|
openvpnserver) that specify a port but no protocol cause
|
|
startup<br>
|
|
errors as follows:<br>
|
|
<br>
|
|
iptables
|
|
v1.3.3: unknown protocol `1194' specified<br>
|
|
Try
|
|
`iptables -h' or 'iptables --help' for more information.<br>
|
|
ERROR:
|
|
Command "/usr/sbin/iptables -A net2fw -p 1194 -s<br>
|
|
0.0.0.0/0
|
|
--sport 1194 -j ACCEPT" Failed<br>
|
|
<br>
|
|
The problem may be worked around by specifying the
|
|
protocol as well<br>
|
|
(e.g., "openvpn:udp:3455).<br>
|
|
<br>
|
|
3) If the previous firewall configuration included a policy other
|
|
than<br>
|
|
ACCEPT in the nat, mangle or raw tables then Shorewall
|
|
would not set<br>
|
|
the policy to ACCEPT. This could result in a ruleset that
|
|
rejected or<br>
|
|
dropped all traffic.<br>
|
|
<br>
|
|
4) Specifying an interface name in the SOURCE column <br>
|
|
of /etc/shorewall/tcrules resulted in a startup error.<br>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;"></span><span
|
|
style="font-weight: bold;">2005-12-01 End of Support for Shorewall versions
|
|
2.0 and 2.2<br>
|
|
<br>
|
|
</span>Effective today, versions 2.0 and 2.2 are no longer supported. This
|
|
means that if you find a bug in one of these releases, we won't fix it and if
|
|
you ask for help with one of these releases, we will not spend much time
|
|
trying to solve your issue.<br>
|
|
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2005-11-25 Shorewall 3.0.2<br>
|
|
</span>
|
|
<pre>Problems Corrected in 3.0.2<br><br>1) A couple of typos in the one-interface sample configuration have<br> been corrected.<br><br>2) The 3.0.1 version of Shorewall was incompatible with old versions of<br> the Linux kernel (2.4.7 for example). The new code ignores errors<br> produced when Shorewall 3.x is run on these ancient kernels.<br><br>3) Arch Linux installation routines has been improved.<br><br>New Features in 3.0.2<br><br>1) A new Webmin macro has been added. This macro assumes that Webmin is<br> running on its default port (10000).<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">2005-11-18 Shorewall 3.0.1</span><br>
|
|
|
|
<pre>Problems Corrected in 3.0.1 <br>
|
|
|
|
1) If the previous firewall configuration included a policy other than
|
|
ACCEPT in the nat, mangle or raw tables then Shorewall would not set
|
|
the policy to ACCEPT. This could result in a ruleset that rejected or
|
|
dropped all traffic.
|
|
|
|
2) The Makefile was broken such that 'make' didn't always work correctly.
|
|
|
|
3) If the SOURCE or DEST column in a macro body was non-empty and a dash
|
|
("-") appeared in the corresponding column of an invocation of that
|
|
macro, then an invalid rule was generated.
|
|
|
|
4) The comments in the /etc/shorewall/blacklist file have been updated to
|
|
clarify that the PORTS column refers to destination port number/service
|
|
names.
|
|
|
|
5) When CLAMPMSS is set to a value other than "No" and FASTACCEPT=Yes, the
|
|
order of the rules generated was incorrect causing RELATED TCP connections
|
|
to not have CLAMPMSS applied.
|
|
|
|
New Features in 3.0.1
|
|
|
|
1) To make the macro facility more flexible, Shorewall now examines the
|
|
contents of the SOURCE and DEST columns in both the macro body and in
|
|
the invocation and tries to create the intended rule. If the value in
|
|
the invocation appears to be an address (IP or MAC) or the name of an
|
|
ipset, then it is placed after the value in the macro body. Otherwise,
|
|
it is placed before the value in the macro body.
|
|
|
|
Example 1:
|
|
|
|
/etc/shorewall/macro.foo:
|
|
|
|
PARAM - 192.168.1.5 tcp http
|
|
|
|
/etc/shorewallrules:
|
|
|
|
foo/ACCEPT net loc
|
|
|
|
Effective rule:
|
|
|
|
ACCEPT net loc:192.168.1.5 tcp http
|
|
|
|
Example 2:
|
|
|
|
/etc/shorewall/macro.bar:
|
|
|
|
PARAM net loc tcp http
|
|
|
|
/etc/shorewall/rules:
|
|
|
|
bar/ACCEPT - 192.168.1.5
|
|
|
|
Effective rule:
|
|
|
|
ACCEPT net loc:192.168.1.5 tcp http</pre>
|
|
|
|
<p></p>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">11/11/2005 Shorewall 3.0.0</span><br>
|
|
|
|
<pre>New Features in Shorewall 3.0.0<br><br>1) Error and warning messages are made easier to spot by using<br> capitalization (e.g., ERROR: and WARNING:).<br><br>2) A new option 'critical' has been added to<br> /etc/shorewall/routestopped. This option can be used to enable<br> communication with a host or set of hosts during the entire<br> "shorewall [re]start/stop" process. Listing a host with this option<br> differs from listing it without the option in several ways:<br><br> a) The option only affect traffic between the listed host(s) and the<br> firewall itself.<br><br> b) If there are any entries with 'critical', the firewall<br> will be completely opened briefly during start, restart and stop but<br> there will be no chance of any packets to/from the listed host(s)<br> being dropped or rejected.<br><br> Possible uses for this option are:<br><br> a) Root file system is NFS mounted. You will want to list the NFS server<br> in the 'critical' option.<br><br> b) You are running Shorewall in a Crossbeam environment<br> (www.crossbeam.com). You will want to list the Crossbeam interface<br> in this option<br><br>3) A new 'macro' feature has been added.<br><br> Macros are very similar to actions and can be used in similar<br> ways. The differences between actions and macros are as follows:<br><br> a) An action creates a separate chain with the same name as the<br> action (when logging is specified on the invocation of an action,<br> a chain beginning with "%" followed by the name of the action and<br> possibly followed by a number is created). When a macro is<br> invoked, it is expanded in-line and no new chain is created.<br><br> b) An action may be specified as the default action for a policy;<br> macros cannot be specified this way.<br><br> c) Actions must be listed in either /usr/share/shorewall/actions.std<br> or in /etc/shorewall/actions. Macros are defined simply by<br> placing their definition file in the CONFIG_PATH.<br><br> d) Actions are defined in a file with a name beginning with<br> "action." and followed by the name of the action. Macro files are<br> defined in a file with a name beginning with "macro.".<br><br> e) Actions may invoke other actions. Macros may not directly invoke<br> other macros although they may invoke other macros indirectly<br> through an action.<br><br> f) DNAT[-] and REDIRECT[-] rules may not appear in an action. They<br> are allowed in a macro with the restriction that the a macro<br> containing one of these rules may not be invoked from an action.<br><br> g) The values specified in the various columns when you invoke a<br> macro are substituted in the corresponding column in each rule in<br> the macro. The first three columns get special treatment:<br><br> ACTION If you code PARAM as the action in a macro then<br> when you invoke the macro, you can include the<br> name of the macro followed by a slash ("/") and<br> an ACTION (either built-in or user-defined. All<br> instances of PARAM in the body of the macro will be<br> replaced with the ACTION.<br><br> Any logging applied when the macro is invoked is<br> applied following the same rules as for actions.<br><br> SOURCE and<br> DEST If the rule in the macro file specifies a value and<br> the invocation of the rule also specifies a value then<br> the value in the invocation is appended to the value<br> in the rule using ":" as a separator.<br><br> Example:<br><br> /etc/shorewall/macro.SMTP<br><br> PARAM - loc tcp 25<br><br> /etc/shorewall/rules:<br><br> SMTP/DNAT:info net 192.168.1.5<br><br> Would be equivalent to the following in the rules file:<br><br> DNAT:info net loc:192.168.1.5 tcp 25<br><br> Rest Any value in the invocation replaces the value in the<br> rule in the macro.<br><br> One additional restriction applies to the mixing of macros and<br> actions. Macros that are invoked from actions cannot themselves<br> invoke other actions.<br><br>4) If you have 'make' installed on your firewall, then when you use<br> the '-f' option to 'shorewall start' (as happens when you reboot),<br> if your /etc/shorewall/ directory contains files that were modified<br> after Shorewall was last restarted then Shorewall is started using<br> the config files rather than using the saved configuration.<br><br>5) The 'arp_ignore' option has been added to /etc/shorewall/interfaces<br> entries. This option sets<br> /proc/sys/net/ipv4/conf/<interface>/arp_ignore. By default, the<br> option sets the value to 1. You can also write arp_ignore=<value><br> where value is one of the following:<br><br> 1 - reply only if the target IP address is local address<br> configured on the incoming interface<br><br> 2 - reply only if the target IP address is local address<br> configured on the incoming interface and both with the sender's<br> IP address are part from same subnet on this interface<br><br> 3 - do not reply for local addresses configured with scope<br> host, only resolutions for global and link addresses are<br> replied<br><br> 4-7 - reserved<br><br> 8 - do not reply for all local addresses<br><br> WARNING -- DO NOT SPECIFY arp_ignore FOR ANY INTERFACE INVOLVED IN<br> PROXY ARP.<br><br>6) In /etc/shorewall/rules, "all+" in the SOURCE or DEST column works<br> like "all" but also includes intrazone traffic. So the rule:<br><br> ACCEPT loc all+ tcp 22<br><br> would allow SSH traffic from loc->loc whereas<br><br> ACCEPT loc all tcp 22<br><br> does not.<br><br>7) A new FASTACCEPT option has been added to shorewall.conf.<br><br> Normally, Shorewall defers accepting ESTABLISHED/RELATED packets<br> until these packets reach the chain in which the original connection<br> was accepted. So for packets going from the 'loc' zone to the 'net'<br> zone, ESTABLISHED/RELATED packets are ACCEPTED in the 'loc2net'<br> chain.<br><br> If you set FASTACCEPT=Yes, then ESTABLISHED/RELEATED packets are<br> accepted early in the INPUT, FORWARD and OUTPUT chains. If you set<br> FASTACCEPT=Yes then you may not include rules in the ESTABLISHED or<br> RELATED sections of /etc/shorewall/rules.<br><br>8) Shorewall now generates an error if the 'norfc1918' option is<br> specified for an interface with an RFC 1918 address.<br><br>9) You may now specify "!" followed by a list of addresses in the<br> SOURCE and DEST columns of entries in /etc/shorewall/rules,<br> /etc/shorewall/tcrules and in action files and Shorewall will<br> generate the rule that you expect.<br><br> Example 1 (/etc/shorewall/rules):<br><br> #ACTION SOURCE DEST PROTO DEST PORT(S)<br> ACCEPT loc:!192.168.1.0/24,10.0.0.0/8 net tcp 80<br><br> That rule would allow loc->net HTTP access except for the local<br> networks 192.168.1.0/24 and 10.0.0.0/8.<br><br> Example 2 (/etc/shorewall/rules):<br><br> #ACTION SOURCE DEST PROTO DEST PORT(S)<br> ACCEPT loc:10.0.0.0/24!10.0.0.4,10.0.0.22 \<br> net tcp 80<br><br> That rule would allow loc->net HTTP access from the local<br> network 10.0.0.0/24 except for hosts 10.0.0.4 and 10.0.0.22.<br><br>10) Tunnel types "openvpnserver" and "openvpnclient" have been added<br> to reflect the introduction of client and server OpenVPN<br> configurations in OpenVPN 2.0.<br><br>11) The COMMAND variable is now set to 'restore' in restore<br> scripts. The value of this variable is sometimes of interest to<br> programmers providing custom /etc/shorewall/tcstart scripts.<br><br>12) Previously, if you defined any intra-zone rule(s) then any traffic<br> not matching the rule(s) was subject to normal policies (which<br> usually turned out to involve the all->all REJECT policy). Now, the<br> intra-zone ACCEPT policy will still be in effect in the presence of<br> intra-zone rules. That policy can still be overridden by an<br> explicit policy in your /etc/shorewall/policy file.<br><br> Example:<br><br> /etc/shorewall/rules:<br><br> DNAT loc:!192.168.1.4 loc:192.168.1.4:3128 tcp 80<br><br> Any other loc->loc traffic will still be accepted. If you want to<br> also log that other loc->loc traffic at the info log level then<br> insert this into /etc/shorewall/policy:<br><br> #SOURCE DEST POLICY LOG LEVEL<br> loc loc ACCEPT info<br><br>13) Prior to Shorewall 2.5.3, the rules file only controlled packets in<br> the Netfilter states NEW and INVALID. Beginning with this release,<br> the rules file can also deal with packets in the ESTABLISHED and<br> RELATED states.<br><br> The /etc/shorewall/rules file may now be divided into<br> "sections". Each section is introduced by a line that begins with<br> the keyword SECTION followed by the section name. Sections<br> are as listed below and must appear in the order shown.<br><br> ESTABLISHED<br><br> Rules in this section apply to packets in the ESTABLISHED<br> state.<br><br> RELATED<br><br> Rules in this section apply to packets in the RELATED state.<br><br> NEW<br><br> Rules in this section apply to packets in the NEW and INVALID<br> states.<br><br> Rules in the ESTABLISHED and RELATED sections are limited to the<br> following ACTIONs:<br><br> ACCEPT, DROP, REJECT, QUEUE, LOG and User-defined actions.<br><br> Macros may be used in these sections provided that they expand to<br> only these ACTIONs.<br><br> At the end of the ESTABLISHED and RELATED sections, there is an<br> implicit "ALLOW all all all" rule.<br><br> RESTRICTION: If you specify FASTACCEPT=Yes in<br> /etc/shorewall.shorewall.conf then the ESTABLISHED and RELATED<br> sections must be empty.<br><br>14) The value 'ipp2p' is once again allowed in the PROTO column of<br> the rules file. It is recommended that rules specifying 'ipp2p'<br> only be included in the ESTABLISHED section of the file.<br><br><br>15) Shorewall actions lack a generalized way to pass parameters to an<br> extension script associated with an action. To work around this<br> lack, some users have used the log tag as a parameter. This works<br> but requires that a log level other than 'none' be specified when<br> the action is invoked. Beginning with this release, you can invoke<br> an action with 'none'.<br><br> Example:<br><br> #ACTION SOURCE DEST<br> A:none:these,are,parameters $FW net<br><br> When /etc/shorewall/A is invoked, the LEVEL variable will be empty<br> but the TAG variable will contain "these,are,parameters" which<br> can be easily parsed to isolate "these", "are" and "parameters":<br><br> ifs=$IFS<br> IFS=,<br> set -- $TAG<br> IFS=$ifs<span style="font-weight: bold;">2</span><br><br> Now, $1 = these, $2 = are and $3 = parameters<br><br>16) The "shorewall check" command now checks the /etc/shorewall/masq,<br> /etc/shorewall/blacklist, /etc/shorewall/proxyarp,<br> /etc/shorewall/nat and /etc/shorewall/providers files.<br><br>17) Arne Bernin's "tc4shorewall" package has been integrated into<br> Shorewall.<br><br> See: http://www.shorewall.net/3.0/traffic_shaping.htm for details.<br><br> Thanks, Arne!<br><br>18) When /usr/share/shorewall/functions is loaded it now sets<br><span style="font-weight: bold;">2</span><br> SHOREWALL_LIBRARY=Loaded<br><br> Application code such as /etc/shorewall/tcstart may test that<br> variable to determine if the library has been loaded into the<br> current shell process.<br><br>19) The install.sh script now does a much cleaner job of backing up the<br> current installation. It copies the directories /etc/shorewall,<br> /usr/share/shorewall and /var/lib/shorewall to a directory of the<br> same name with "-$VERSION.bkout" appended. The init script and<br> /sbin/shorewall are backed up to the /usr/share/shorewall and<br> /var/lib/shorewall directories respectively. This makes it very<br> simple to remove the backups:<br><br> rm -rf /etc/shorewall-*.bkout<br> rm -rf /usr/share/shorewall-*.bkout<br> rm -rf /var/lib/shorewall-*.bkout<br><br>20) A new '-n' option has been added to the "start", "restart",<br> "restore", "stop" and "try" commands. This option instructs<br> Shorewall to not alter the routing in any way.<br><br> This option is useful when you have a multi-ISP environment because<br> it prevents the route cache from being flushed which preserves the<br> mapping of end-point address pairs to routes.<br><br>21) The output of "shorewall dump" now includes a capabilities report<br> such as the one produced by "shorewall show capabilities".<br><br>22) The "plain" zone type has been replaced by "ipv4". The types<br> "IPv4" and "IPV4" are synonyms for "ipv4". In addition, "IPSEC",<br> "ipsec4" and "IPSEC4" are recognized synonyms for "ipsec".<br><br>23) The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been<br> removed as have the 'newnotsyn' options in /etc/shorewall/interfaces<br> and /etc/shorewall/hosts. See the Migration Considerations for<br> instructions if you wish to block "new-not-syn" TCP packets.<br><br>24) The "shorewall show zones" command now displays the zone type. You<br> must have restarted Shorewall using this release before this feature<br> will work correctly.<br><br>25) The multi-ISP code now requires that that you set MARK_IN_FORWARD_CHAIN=Yes<br> in shorewall.conf. This is done to ensure that "shorewall refresh" will<br> work correctly.<br><br>26) Shorewall now supports UDP IPP2P matching. In addition to the "ipp2p"<br> keyword in the PROTOCOL column of the relevant files, the following<br> values may be specified:<br><br> ipp2p:tcp Equivalent to ipp2p and matches TCP traffic<br> only.<br> ipp2p:udp Matches UDP traffic.<br> ipp2p:all Matches both UDP and TCP traffic. You may<br> not specify a SOURCE PORT with this PROTOCOL.<br><br>27) Normally MAC verification triggered by the 'maclist' interface and host<br> options is done out of the INPUT and FORWARD chains of the filter table.<br> Users have reported that under some circumstances, MAC verification is<br> failing for forwarded packets when the packets are being forwarded out<br> of a bridge.<br><br> To work around this problem, a MACLIST_TABLE option has been added to<br> shorewall.conf. The default value is MACLIST_TABLE=filter which results<br> in the current behavior. If MACLIST_TABLE=mangle then filtering will<br> take place out of the PREROUTING chain of the mangle table. Because<br> the REJECT target may not be used in the PREROUTING chain, the settings<br> MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.<br><br>28) The sample configurations are now packaged with the product. They are<br> in the Samples directory on the tarball and are in the RPM they are<br> in the Samples sub-directory of the Shorewall documentation<br> directory.<br></pre>
|
|
<span style="font-weight: bold;"></span>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">10/31/2005 Shorewall 2.4.6<br>
|
|
<br>
|
|
</span>Problems Corrected in 2.4.6<br>
|
|
|
|
<ol>
|
|
<li>"shorewall refresh" would fail if there were entries in
|
|
/etc/shorewall/tcrules with non-empty USER/GROUP or TEST columns.</li>
|
|
<li>An unprintable character in a comment caused /sbin/shorewall to fail
|
|
when used with a light-weight shell like 'dash'.</li>
|
|
<li>When using some flavors of 'ash', certain /sbin/shorewall commands
|
|
produced 'ipset: not found' messages.</li>
|
|
<li>Support for OpenVPN TCP tunnels was released in Shorewall 2.2.0 but the
|
|
implementation was incomplete. It has now been completed and is
|
|
documented in the /etc/shorewall/tunnels file.</li>
|
|
<li>The test that Shorewall uses to detect the availability of the owner
|
|
match capability has been changed to avoid the generation of ipt_owner
|
|
messages under kernel 2.6.14.</li>
|
|
</ol>
|
|
New Features in 2.4.6<br>
|
|
|
|
<ol>
|
|
<li>Normally MAC verification triggered by the 'maclist' interface and host
|
|
options is done out of the INPUT and FORWARD chains of the filter table.
|
|
Users have reported that under some circulstances, MAC verification is
|
|
failing for forwarded packets when the packets are being forwarded out of
|
|
a bridge.<br>
|
|
<br>
|
|
To work around this problem, a MACLIST_TABLE option has been added to
|
|
shorewall.conf. The default value is MACLIST_TABLE=filter which results
|
|
in the current behavior. If MACLIST_TABLE=mangle then filtering will take
|
|
place out of the PREROUTING chain of the mangle table. Because the REJECT
|
|
target may not be used in the PREROUTING chain, the settings
|
|
MACLIST_DISPOSITION=REJECT and MACLIST_TABLE=mangle are incompatible.</li>
|
|
<li>A "dump" command has been added to /sbin/shorewall for compatibility
|
|
with Shorewall 3.0. In 2.4.6, the "dump" command provides the same output
|
|
as the "status".<br>
|
|
</li>
|
|
</ol>
|
|
<hr style="width: 100%; height: 2px;">
|
|
Shorewall 2.4.5<br>
|
|
<br>
|
|
Problems Corrected in 2.4.5<br>
|
|
|
|
<ol>
|
|
<li>In previous versions, when the command is 'start', 'restart' or 'stop'
|
|
then OUTPUT traffic to hosts listed in /etc/shorewall/routestopped is not
|
|
enabled if ADMINISABSENTMINDED=Yes. That traffic is now enabled
|
|
independent of the setting of ADMINISABSENTMINDED.</li>
|
|
<li>Although it was documented that icmp types could be used in the tcrules
|
|
file, the code did not support it. Thanks to Jorge Molina, that problem
|
|
is now corrected.</li>
|
|
<li>In a multi-ISP configuration, fwmark routing rules now have a higher
|
|
priority than source IP rules. This allows entries in tcrules to be more
|
|
effective in controlling routing.</li>
|
|
<li>Previously, not all of the mangle chains were flushed during "shorewall
|
|
restart".</li>
|
|
</ol>
|
|
<span style="font-weight: bold;">09/12/2005 Shorewall 2.4.4<br>
|
|
</span><br>
|
|
Problems Corrected<br>
|
|
|
|
<ol>
|
|
<li>An incorrect comment in the /etc/shorewall/proxyarp file has been
|
|
removed.</li>
|
|
<li>The message generated when a duplicate policy has been entered is now
|
|
more informative. Previously, only the POLICY column contents appeared in
|
|
the message. Now the SOURCE, DEST and POLICY column contents are
|
|
shown.</li>
|
|
<li>Shorewall now clears the Netfilter "raw" table during "shorewall
|
|
[re]start", "shorewall stop" and "shorewall clear" processing.</li>
|
|
</ol>
|
|
New Features<br>
|
|
|
|
<ol>
|
|
<li>Tunnel types "openvpnserver" and "openvpnclient" have been added to
|
|
reflect the introduction of client and server OpenVPN configurations in
|
|
OpenVPN 2.0.</li>
|
|
<li>The COMMAND variable is now set to 'restore' in restore scripts. The
|
|
value of this variable is sometimes of interest to programmers providing
|
|
custom /etc/shorewall/tcstart scripts.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;">08/16/2005 Shorewall 2.4.3<br>
|
|
</span><br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>Shorewall is no longer dependent on the 'which' utility.</li>
|
|
<li>The 'shorewall add' command failed if there existed a zone in the
|
|
configuration that specified the 'ipsec' option in
|
|
/etc/shorewall/hosts.</li>
|
|
<li>Shorewall is no longer dependent on /bin/echo.</li>
|
|
<li>A CLASSIFY rule with $FW in the SOURCE column (tcrules) no longer
|
|
results in a "shorewall start" error.</li>
|
|
<li>You may now use port lists in the DEST PORT and SOURCE PORT columns of
|
|
the /etc/shorewall/accounting file.</li>
|
|
<li>The "shorewall show capabilities" command now accurately reports the
|
|
availability of "Packet type match" independent of the setting of PKTTYPE
|
|
in shorewall.conf.</li>
|
|
<li>Thanks to Tuomo Soini, all of the files have been siginificantly
|
|
cleaned up in terms of formatting and extra white-space.<br>
|
|
</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>New Allow.Submission and Allow.NTPbrd actions have been added. Users of
|
|
the Allow.NTP action that use NTP broadcasting should switch to use of
|
|
Allow.NTPbrd instead.</li>
|
|
<li>The kernel version string is now included in the output of "shorewall
|
|
status".<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;">07/30/2005 Shorewall 2.2.6<br>
|
|
<br>
|
|
</span>Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li><a href="#20050717">MACLIST_TTL Vulnerability</a> fix.</li>
|
|
<li>TCP_FLAGS_LOG_LEVEL=ULOG breaks with recent versions of iptables.</li>
|
|
<li>The bogons file has been updated to reflect recent IANA
|
|
allocations.</li>
|
|
</ol>
|
|
<span style="font-weight: bold;">07/21/2005 Shorewall 2.4.2<br>
|
|
<br>
|
|
</span>Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>The /etc/shorewall/hosts file now includes information about defining a
|
|
zone using one or more ipsets.</li>
|
|
<li>A <a href="#20050717">vulnerability involving MACLIST_TTL > 0 or
|
|
MACLIST_DISPOSITION=ACCEPT</a> has been corrected.</li>
|
|
<li>It is now possible to specify !<address> in the SUBNET column of
|
|
/etc/shorewall/masq. Previously, it was necessary to write
|
|
0.0.0.0/0!<address>.</li>
|
|
<li>When <network1>!<network2> was specified in the SUBNET
|
|
column of /etc/shorewall/masq, IPSEC policies were not correctly applied
|
|
to the resulting rules. This usually resulted in IPSEC not working
|
|
through the interface specified in the INTERFACES column.<br>
|
|
</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>A 'loose' provider option has been added. If you wish to be able to use
|
|
marking to specify the gateway used by connections originating on the
|
|
firewall itself, the specify 'loose' for each provider. It has bee
|
|
reported that 'loose' may break the effect of 'track' so beware if you
|
|
need 'track' functionality (you shouldn't be originating many connections
|
|
from your firewall to the net anyway).<br>
|
|
<br>
|
|
To use 'loose', you also need to add two entries in
|
|
/etc/shorewall/masq:<br>
|
|
|
|
<pre><span style="font-family: monospace;">#INTERFACE SUBNET ADDRESS<br>
|
|
$IF_ISP1 $IP_ISP2 $IP_ISP1<br>
|
|
$IF_ISP2 $IP_ISP1 $IP_ISP2</span>
|
|
</pre>
|
|
where:<br>
|
|
|
|
<pre> $IF_ISP1 is the interface to ISP 1.<br>
|
|
$IF_ISP2 is the interface to ISP 2.<br>
|
|
$IP_ISP1 is the IP address of $IF_ISP1<br>
|
|
$IP_ISP2 is the IP address of $IF_ISP2
|
|
</pre>
|
|
</li>
|
|
<li>/sbin/shorewall now issues a warning each time that it finds that
|
|
startup is disabled.</li>
|
|
<li>A new COPY column has been added to the /etc/shorewall/providers file.
|
|
Normally, when a table name/number is given in the DUPLICATE column, the
|
|
entire table (less default routes) is copied. The COPY column allows you
|
|
to limit the routes copied to those that go through an interface listed
|
|
in COPY. For example, if you enter eth0 in INTERFACE, "eth1,eth2" in COPY
|
|
and 'main' in DUPLICATE then the new table created will contain those
|
|
routes through the interfaces eth0, eth1 and eth2.<br>
|
|
</li>
|
|
</ol>
|
|
<hr style="width: 100%; height: 2px;">
|
|
|
|
<h2><a name="20050717"></a><font color="#ff0000">07/17/2005 Security
|
|
vulnerability in MACLIST processing</font></h2>
|
|
|
|
<h3>Description</h3>
|
|
|
|
<p>A security vulnerability has been discovered which affects all supported
|
|
stable versions of Shorewall. This vulnerability enables a client
|
|
accepted by MAC address filtering to bypass any other rule. If
|
|
MACLIST_TTL is set to a value greater than 0 or MACLIST_DISPOSITION is set to
|
|
"ACCEPT" in /etc/shorewall/shorewall.conf (default is MACLIST_TTL=0 and
|
|
MACLIST_DISPOSITION=REJECT), and a client is positively identified through
|
|
its MAC address, it bypasses all other policies/rules in place, thus gaining
|
|
access to all open services on the firewall.</p>
|
|
|
|
<h3>Fix</h3>
|
|
|
|
<h4>Workaround</h4>
|
|
|
|
<p>For Shorewall 2.2.x or 2.4.x, set MACLIST_TTL=0 or
|
|
MACLIST_DISPOSITION=REJECT in /etc/shorewall/shorewall.conf. For
|
|
Shorewall 2.0.x, set MACLIST_DISPOSITION=REJECT in
|
|
/etc/shorewall/shorewall.conf. MACLIST filtering is of limited value on
|
|
Internet-connected hosts, and the Shorewall team recommends this approach to
|
|
be used if possible.</p>
|
|
|
|
<h4>Upgrade</h4>
|
|
|
|
<p>For Shorewall 2.4.x, a fixed version of the 'firewall' script is available
|
|
at: <a
|
|
href="http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>
|
|
and its mirrors, <a
|
|
href="http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>
|
|
and <a
|
|
href="http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>.</p>
|
|
|
|
<p>For Shorewall 2.2.x, a fixed version of the 'firewall' script is available
|
|
at: <a
|
|
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>
|
|
and its mirrors, <a
|
|
href="http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>
|
|
and <a
|
|
href="http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>.</p>
|
|
|
|
<p>For Shorewall 2.0.x, a fixed version of the 'firewall' script is available
|
|
at: <a
|
|
href="http://shorewall.net/pub/shorewall/errata/2.0.17/firewall">http://shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>
|
|
and its mirrors, <a
|
|
href="http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall">http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>
|
|
and <a
|
|
href="http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall">http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>.</p>
|
|
|
|
<p>Users of any version before 2.0.17 are urged to upgrade to a supported
|
|
version of Shorewall (preferably 2.4.1) before using the fixed files.
|
|
Only the most recent version of the 2.0.x and 2.2.x streams will be supported
|
|
by the development team, and the 1.x branches are no longer maintained at
|
|
all. Future releases of Shorewall will include this fix.</p>
|
|
|
|
<p>This information was based on <a
|
|
href="http://seclists.org/lists/fulldisclosure/2005/Jul/0409.html">Patrick
|
|
Blitz's post to the Full Disclosure mailing list</a>. Thanks to
|
|
Supernaut (supernaut at ns dot sympatico dot ca) for reporting this bug.<br>
|
|
</p>
|
|
|
|
<p><span style="font-weight: bold;">Version Upgrade<br>
|
|
</span></p>
|
|
|
|
<p>The vulnerability is corrected in Shorewall 2.4.2 and in Shorewall
|
|
2.2.6.<br>
|
|
</p>
|
|
<hr style="width: 100%; height: 2px;">
|
|
<span style="font-weight: bold;">07/13/2005 Shorewall 2.4.1<br>
|
|
</span><br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>Shell variables may now be used in the zones file.</li>
|
|
<li>The /usr/share/shorewall/bogons file has been updated to reflect recent
|
|
IANA allocations.</li>
|
|
<li>Shorewall now detects an error where multiple providers specify the
|
|
'track' option on the same interface.</li>
|
|
<li>The remnants of the GATEWAY column in /etc/shorewall/interfaces have
|
|
been removed. This column appeared briefly in one of the Beta versions
|
|
and was immediately removed but some vestiges remained.</li>
|
|
<li>Shorewall now correctly restores a load-balancing default route during
|
|
processing of the 'shorewall restore' and 'shorewall -f start' commands.
|
|
The latter command is normally executed by the Shorewall init script
|
|
during reboot.</li>
|
|
<li>A log level of "None!" is now allowed on builtin actions such as ACCEPT
|
|
and DROP.</li>
|
|
<li>Previously, LIMIT:BURST parameters in /etc/shorewall/policy were not
|
|
correctly applied when the policy was QUEUE.</li>
|
|
<li>The 'chkconfig' command on FC4 and Mandriva previously created symbolic
|
|
links with incorrect names ("S-1shorewall"). The init script has been
|
|
changed to prevent this incorrect behavior.</li>
|
|
<li>DHCP traffic forwarded through a bridge could, under some
|
|
configurations, be filtered by the 'maclist' option even though the
|
|
'dhcp' option was specified. This has been corrected.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;">06/05/2005 Shorewall 2.4.0<br>
|
|
<br>
|
|
Note:</span> Because of the short time that has elapsed since the release of
|
|
Shorewall 2.2.0, Shorewall 2.0 will be supported until 1 December 2005 or
|
|
until the release of Shorewall 2.6.0, whichever occurs first.<br>
|
|
<br>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>Shorewall 2.4.0 includes support for multiple internet interfaces to
|
|
different ISPs.<br>
|
|
<br>
|
|
The file /etc/shorewall/providers may be used to define the different
|
|
providers. It can actually be used to define alternate routing tables so
|
|
uses like transparent proxy can use the file as well.<br>
|
|
<br>
|
|
Columns are:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">
|
|
NAME
|
|
The provider name.</span><br style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
NUMBER The provider
|
|
number -- a number between 1 and 15</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
MARK A
|
|
FWMARK value used in your /etc/shorewall/tcrules file to direct packets
|
|
for this provider.</span><br style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
DUPLICATE The name of an existing
|
|
table to duplicate. May</span> <span style="font-family: monospace;">be
|
|
'main' or the name of a previous provider.</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
INTERFACE The name of the network
|
|
interface to the</span> <span style="font-family: monospace;">provider.
|
|
Must be listed in</span><span
|
|
style="font-family: monospace;">/etc/shorewall/interfaces.</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
GATEWAY The IP address of
|
|
the provider's gateway router.</span> <span
|
|
style="font-family: monospace;">If you enter "detect" here then
|
|
Shorewall<br>
|
|
|
|
will</span> <span style="font-family: monospace;">attempt to determine
|
|
the gateway IP address</span> <span
|
|
style="font-family: monospace;">automatically.</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
OPTIONS A comma-separated
|
|
list selected from the</span> <span
|
|
style="font-family: monospace;">following:</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
track If specified, connections FROM this interface
|
|
are</span> <span style="font-family: monospace;">to be tracked so that
|
|
responses may be<br>
|
|
|
|
routed</span> <span style="font-family: monospace;">back out this same
|
|
interface.</span><br style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
You want specify 'track' if internet hosts will be</span> <span
|
|
style="font-family: monospace;">connecting to local servers through<br>
|
|
|
|
this</span> <span style="font-family: monospace;">provider.</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
Because of limitations in the 'ip' utility and</span> <span
|
|
style="font-family: monospace;">policy routing, you may not use the SAVE
|
|
or</span><span style="font-family: monospace;"><br>
|
|
|
|
RESTORE tcrules options or use connection</span><span
|
|
style="font-family: monospace;">marking on any traffic to or from
|
|
this</span><br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
interface. For traffic control purposes, you</span> <span
|
|
style="font-family: monospace;">must mark packets in the FORWARD chain
|
|
(or</span><span style="font-family: monospace;"><br>
|
|
|
|
better yet, use the CLASSIFY target).</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
balance The providers that have 'balance' specified will</span> <span
|
|
style="font-family: monospace;">get outbound traffic load-balanced
|
|
among<br>
|
|
|
|
them. By</span> <span style="font-family: monospace;">default, all
|
|
interfaces with 'balance' specified</span> <span
|
|
style="font-family: monospace;">will have the same weight (1).<br>
|
|
|
|
You can change the</span><span style="font-family: monospace;">weight of
|
|
the route out of the interface by</span> <span
|
|
style="font-family: monospace;">specifiying balance=<weight><br>
|
|
|
|
where <weight> is</span><span style="font-family: monospace;">the
|
|
desired route weight.</span><br style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
Example: You run squid in your
|
|
DMZ on IP address 192.168.2.99. Your DMZ interface is eth2<br>
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
#NAME NUMBER MARK DUPLICATE INTERFACE
|
|
GATEWAY OPTIONS</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
Squid 1
|
|
1
|
|
-
|
|
eth2 192.168.2.99 -</span><br>
|
|
<br>
|
|
Use of this feature requires that your kernel and iptabls support
|
|
CONNMARK target and conntrack match support. It does NOT require the
|
|
ROUTE target extension.<br>
|
|
<br>
|
|
WARNING: The current version of iptables (1.3.1) is broken with respect
|
|
to CONNMARK and iptables-save/iptables-restore. This means that if you
|
|
configure multiple ISPs, "shorewall restore" may fail. You must patch
|
|
your iptables using the patch at <a
|
|
href="http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff">http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff</a>.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall 2.3.0 supports the 'cmd-owner' option of the owner match
|
|
facility in Netfilter. Like all owner match options, 'cmd-owner' may only
|
|
be applied to traffic that originates on the firewall.<br>
|
|
<br>
|
|
The syntax of the USER/GROUP column in the following files has been
|
|
extended:<br>
|
|
<br>
|
|
/etc/shorewall/accounting<br>
|
|
/etc/shorewall/rules<br>
|
|
/etc/shorewall/tcrules<br>
|
|
|
|
/usr/share/shorewall/action.template<br>
|
|
<br>
|
|
To specify a command, prefix the command name with "+".<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">
|
|
+mozilla-bin
|
|
#The program is named "mozilla-bin"</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
joe+mozilla-bin #The
|
|
program is named "mozilla-bin" and</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
#is being run by user "joe"</span><br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
joe:users+mozilla-bin #The program is named "mozilla-bin"
|
|
and</span><br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
#is being run by user "joe" with</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
#effective group "users".</span><br style="font-family: monospace;">
|
|
<br>
|
|
Note that this is not a particularly robust feature and I
|
|
would never advertise it as a "Personal Firewall" equivalent. Using
|
|
symbolic links, it's easy to alias command names to be anything you
|
|
want.<br>
|
|
<br>
|
|
</li>
|
|
<li>Support has been added for ipsets (see <a
|
|
href="http://people.netfilter.org/kadlec/ipset/">http://people.netfilter.org/kadlec/ipset/</a>).<br>
|
|
<br>
|
|
In most places where a host or network address may be used, you may also
|
|
use the name of an ipset prefaced by "+".<br>
|
|
<br>
|
|
Example: "+Mirrors"<br>
|
|
<br>
|
|
The name of the set may be optionally followed by:<br>
|
|
<br>
|
|
a) a number from 1 to 6 enclosed in square brackets ([]) -- this number
|
|
indicates the maximum number of ipset binding levels that are to be
|
|
matched. Depending on the context where the ipset name is used, either
|
|
all "src" or all "dst" matches will be used.<br>
|
|
<br>
|
|
Example: "+Mirrors[4]"<br>
|
|
<br>
|
|
b) a series of "src" and "dst" options separated by commas and inclosed
|
|
in square brackets ([]). These will be passed directly to iptables in the
|
|
generated --set clause. See the ipset documentation for details.<br>
|
|
<br>
|
|
Example:
|
|
"+Mirrors[src,dst,src]"<br>
|
|
<br>
|
|
Note that "+Mirrors[4]" used in the SOURCE column of the rules file is
|
|
equivalent to "+Mirrors[src,src,src,src]".<br>
|
|
<br>
|
|
To generate a negative match, prefix the "+" with "!" as in
|
|
"!+Mirrors".<br>
|
|
<br>
|
|
Example 1: Blacklist all hosts in an ipset named "blacklist"<br>
|
|
<br>
|
|
|
|
/etc/shorewall/blacklist<br>
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
#ADDRESS/SUBNET
|
|
PROTOCOL PORT</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
+blacklist</span><br style="font-family: monospace;">
|
|
<br>
|
|
Example 2: Allow SSH from all hosts in an ipset named "sshok:<br>
|
|
<br>
|
|
|
|
/etc/shorewall/rules<br>
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
#ACTION
|
|
SOURCE DEST
|
|
PROTO DEST PORT(S)</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
ACCEPT
|
|
+sshok
|
|
fw tcp
|
|
22</span><br style="font-family: monospace;">
|
|
<br>
|
|
Shorewall can automatically capture the contents of your ipsets for you.
|
|
If you specify SAVE_IPSETS=Yes in /etc/shorewall/shorewall.conf then
|
|
"shorewall save" will save the contents of your ipsets. The file where
|
|
the sets are saved is formed by taking the name where the Shorewall
|
|
configuration is stored and appending "-ipsets". So if you enter the
|
|
command "shorewall save standard" then your Shorewall configuration will
|
|
be saved in var/lib/shorewall/standard and your ipset contents will be
|
|
saved in /var/lib/shorewall/standard-ipsets. Assuming the default
|
|
RESTOREFILE setting, if you just enter "shorewall save" then your
|
|
Shorewall configuration will be saved in /var/lib/shorewall/restore and
|
|
your ipset contents will be saved in
|
|
/var/lib/shorewall/restore-ipsets.<br>
|
|
<br>
|
|
Regardless of the setting of SAVE_IPSETS, the "shorewall -f start" and
|
|
"shorewall restore" commands will restore the ipset contents
|
|
corresponding to the Shorewall configuration restored provided that the
|
|
saved Shorewall configuration specified exists.<br>
|
|
<br>
|
|
For example, "shorewall restore standard" would restore the ipset
|
|
contents from /var/lib/shorewall/standard-ipsets provided that
|
|
/var/lib/shorewall/standard exists and is executable and that
|
|
/var/lib/shorewall/standard-ipsets exists and is executable.<br>
|
|
<br>
|
|
Also regardless of the setting of SAVE_IPSETS, the "shorewall forget"
|
|
command will purge the saved ipset information (if any) associated with
|
|
the saved shorewall configuration being removed.<br>
|
|
<br>
|
|
You can also associate ipset contents with Shorewall configuration
|
|
directories using the following command:<br>
|
|
<br>
|
|
ipset -S > <config
|
|
directory>/ipsets<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
ipset -S >
|
|
/etc/shorewall/ipsets<br>
|
|
<br>
|
|
When you start or restart Shorewall (including using the 'try' command)
|
|
from the configuration directory, your ipsets will be configured from the
|
|
saved ipsets file. Once again, this behavior is independent of the
|
|
setting of SAVE_IPSETS.<br>
|
|
<br>
|
|
Ipsets are well suited for large blacklists. You can maintain your
|
|
blacklist using the 'ipset' utility without ever having to restart or
|
|
refresh Shorewall. If you use the SAVE_IPSETS=Yes feature just be sure to
|
|
"shorewall save" after altering the blacklist ipset(s).<br>
|
|
<br>
|
|
Example /etc/shorewall/blacklist:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">
|
|
#ADDRESS/SUBNET
|
|
PROTOCOL PORT</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
+Blacklist[src,dst]</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
+Blacklistnets[src,dst]</span><br style="font-family: monospace;">
|
|
<br>
|
|
Create the blacklist ipsets using:<br>
|
|
<br>
|
|
ipset -N Blacklist
|
|
iphash<br>
|
|
ipset -N
|
|
Blacklistnets nethash<br>
|
|
<br>
|
|
Add entries<br>
|
|
<br>
|
|
ipset -A Blacklist
|
|
206.124.146.177<br>
|
|
ipset -A Blacklistnets
|
|
206.124.146.0/24<br>
|
|
<br>
|
|
To allow entries for individual ports<br>
|
|
<br>
|
|
ipset -N SMTP portmap --from 1 --to
|
|
31<br>
|
|
ipset -A SMTP 25<br>
|
|
<br>
|
|
ipset -A Blacklist
|
|
206.124.146.177<br>
|
|
ipset -B Blacklist 206.124.146.177
|
|
-b SMTP<br>
|
|
<br>
|
|
Now only port 25 will be blocked from 206.124.146.177.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall 2.4.0 can now configure routing if your kernel and iptables
|
|
support the ROUTE target extension. This extension is available in
|
|
Patch-O-Matic-ng. This feature is *EXPERIMENTAL* since the Netfilter team
|
|
have no intention of ever releasing the ROUTE target extension to
|
|
kernel.org.<br>
|
|
<br>
|
|
Routing is configured using the /etc/shorewall/routes file. Columns in
|
|
the file are as follows:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">
|
|
SOURCE
|
|
Source of the packet. May be any of the</span> <span
|
|
style="font-family: monospace;">following:</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
- A host or network address</span><br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
- A network interface name.</span><br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
- The name of an ipset prefaced with "+"</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
- $FW (for packets originating on the firewall)</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
- A MAC address in Shorewall format</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
- A range of IP addresses (assuming that your</span> <span
|
|
style="font-family: monospace;">kernel and iptables support range
|
|
match)</span><br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
- A network interface name followed by ":"</span> <span
|
|
style="font-family: monospace;">and an address or address
|
|
range.</span><br style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
DEST
|
|
Destination of the packet. May be any of the</span> <span
|
|
style="font-family: monospace;">following:</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
- A host or network address</span><br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
- A network interface name (determined from</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
routing table(s))</span><br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
- The name of an ipset prefaced with "+"</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
- A network interface name followed by ":"</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
and an address or address range.</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
PROTO
|
|
Protocol - Must be "tcp", "udp", "icmp",</span> <span
|
|
style="font-family: monospace;">"ipp2p", a number, or "all". "ipp2p"
|
|
requires</span><span style="font-family: monospace;"><br>
|
|
|
|
ipp2p match support in your kernel and</span><span
|
|
style="font-family: monospace;">iptables.</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
PORT(S) Destination
|
|
Ports. A comma-separated list of</span> <span
|
|
style="font-family: monospace;">Port names (from /etc/services), port<br>
|
|
|
|
numbers</span> <span style="font-family: monospace;">or port ranges; if
|
|
the protocol is "icmp", this</span><span
|
|
style="font-family: monospace;">column is interpreted as the<br>
|
|
|
|
destination</span> <span
|
|
style="font-family: monospace;">icmp-type(s).</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
If the protocol is ipp2p, this column is</span> <span
|
|
style="font-family: monospace;">interpreted as an ipp2p option without
|
|
the</span><span style="font-family: monospace;"><br>
|
|
|
|
leading "--" (example "bit" for bit-torrent).</span> <span
|
|
style="font-family: monospace;">If no PORT is given, "ipp2p" is
|
|
assumed.</span><br style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
This column is ignored if PROTOCOL = all but</span> <span
|
|
style="font-family: monospace;">must be entered if any of the
|
|
following<br>
|
|
|
|
field</span> <span style="font-family: monospace;">is supplied. In that
|
|
case, it is suggested that</span> <span
|
|
style="font-family: monospace;">this field contain "-"</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
SOURCE PORT(S) (Optional) Source port(s). If omitted,</span> <span
|
|
style="font-family: monospace;">any source port is acceptable. Specified
|
|
as a</span><span style="font-family: monospace;"><br>
|
|
|
|
comma-separated list of port names, port</span> <span
|
|
style="font-family: monospace;">numbers or port ranges.</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
TEST
|
|
Defines a test on the existing packet or</span> <span
|
|
style="font-family: monospace;">connection mark.</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
The rule will match only if the test returns</span> <span
|
|
style="font-family: monospace;">true. Tests have the format</span><span
|
|
style="font-family: monospace;"><br>
|
|
|
|
[!]<value>[/<mask>][:C]</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
Where:</span><br style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
! Inverts the test (not equal)</span>
|
|
<span style="font-family: monospace;"><value> Value of the packet
|
|
or</span><span style="font-family: monospace;"><br>
|
|
|
|
connection mark.</span><br style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
<mask> A mask to be applied to the</span> <span
|
|
style="font-family: monospace;">mark before testing</span><br
|
|
style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
:C Designates a connection</span> <span
|
|
style="font-family: monospace;">mark. If omitted, the packet</span> <span
|
|
style="font-family: monospace;">mark's value<br>
|
|
|
|
is tested.</span><br style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
INTERFACE The interface that the
|
|
packet is to be routed</span> <span style="font-family: monospace;">out
|
|
of. If you do not specify this<br>
|
|
|
|
field then</span> <span style="font-family: monospace;">you must place
|
|
"-" in this column and enter an</span> <span
|
|
style="font-family: monospace;">IP address in the GATEWAY<br>
|
|
|
|
column.</span><br style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">
|
|
GATEWAY The gateway that
|
|
the packet is to be forewarded</span> <span
|
|
style="font-family: monospace;">through.</span><br
|
|
style="font-family: monospace;">
|
|
<br style="font-family: monospace;">
|
|
</li>
|
|
<li>Normally when Shorewall is stopped, starting or restarting then
|
|
connections are allowed from hosts listed in /etc/shorewall/routestopped
|
|
to the firewall and to other hosts listed in
|
|
/etc/shorewall/routestopped.<br>
|
|
<br>
|
|
A new 'source' option is added for entries in that file which will cause
|
|
Shorewall to allow traffic from the host listed in the entry to ANY other
|
|
host. When 'source' is specified in an entry, it is unnecessary to also
|
|
specify 'routeback'.<br>
|
|
<br>
|
|
Similarly, a new 'dest' option is added which will cause Shorewall to
|
|
allow traffic to the host listed in the entry from ANY other host. When
|
|
'source' is specified in an entry, it is unnecessary to also specify
|
|
'routeback'.<br>
|
|
<br>
|
|
</li>
|
|
<li>This change was implemented by Lorenzo Martignoni. It provides two new
|
|
commands: "safe-start" and "safe-restart".<br>
|
|
<br>
|
|
<span style="font-weight: bold;">safe-start</span> starts Shorewall then
|
|
prompts you to ask you if everything looks ok. If you answer "no" or if
|
|
you don't answer within 60 seconds, a "shorewall clear" is executed.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">safe-restart</span> saves your current
|
|
configuration to /var/lib/shorewall/safe-restart then issues a "shorewall
|
|
restart"; It then prompts you to ask if you if you want to accept the new
|
|
configuration. If you answer "no" or if you don't answer within 60
|
|
seconds, the configuration is restored to its prior state.<br>
|
|
<br>
|
|
These new commands require either that your /bin/sh supports the "-t"
|
|
option to the 'read' command or that you have /bin/bash installed.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;">05/20/2005 Shorewall CVS Repository
|
|
has Moved to Sourceforge<br>
|
|
<br>
|
|
</span> The CVS repository may now be accessed at <a target="_top"
|
|
href="http://sourceforge.net/cvs/?group_id=22587">http://sourceforge.net/cvs/?group_id=22587</a>.<br>
|
|
<span style="font-weight: bold;"><br>
|
|
05/20/2005 Shorewall 2.2.5<br>
|
|
<br>
|
|
</span> This will be my last 2.2 release. It contains a couple of small bug
|
|
fixes that I hadn't yet released.<br>
|
|
<br>
|
|
-Tom<br>
|
|
<br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>Previously, if PKTTYPE=No in shorewall.conf then pkttype match would
|
|
still be used if the kernel supported it.</li>
|
|
<li>A typo in the 'tunnel' script has been corrected (Thanks to Patrik
|
|
Varmecký).</li>
|
|
<li>A warning is now generated if an invalid short zone name is used in
|
|
/etc/shorewall/zones.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;">05/18/2005 Tom stepping away from Shorewall
|
|
development and support<br>
|
|
</span> <br>
|
|
It is with regret that I announce that my involvement in Shorewall
|
|
development and support is officially ending.<br>
|
|
<br>
|
|
Unlike the originators of other successful open source projects, I have not
|
|
been able to attract a core of people who believe in Shorewall and who are
|
|
willing to make sacrifices to ensure it's success. That is my weakness and I
|
|
accept it. But is means that I have been left with trying to develop,
|
|
document, and support Shorewall almost single-handedly. I cannot do it any
|
|
more.<br>
|
|
<br>
|
|
I will clean up what I have for a 2.3 release and place it on the server as
|
|
my last Shorewall release -- Shorewall 2.4.0.<br>
|
|
<br>
|
|
Discussions aimed at continuing Shorewall development under new leadership
|
|
are continuing.<br>
|
|
<br>
|
|
Shorewall will always be a part of my life that I look back on with
|
|
fondness.<br>
|
|
<br>
|
|
Regards,<br>
|
|
<br>
|
|
-Tom<br>
|
|
|
|
|
|
<p><span style="font-weight: bold;">05/02/2005 Shorewall 2.2.4<br>
|
|
</span></p>
|
|
|
|
<p>Problems Corrected:<br>
|
|
</p>
|
|
<ol>
|
|
<li>The error message:<br>
|
|
<br>
|
|
Error: No appropriate chain for zone
|
|
<z1> to zone <z2><br>
|
|
<br>
|
|
has been changed to one that is more self-explanatory:<br>
|
|
<br>
|
|
Error: No policy defined for zone
|
|
<z1> to zone <z2></li>
|
|
<li>When only an interface name appeared in the HOST(S) column of an
|
|
/etc/shorewall/hosts file entry, a misleading iptables error message
|
|
resulted. Now the following message is generated:<br>
|
|
<br>
|
|
Error: Invalid HOST(S) column
|
|
contents: <column contents></li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>Support has been added for UPnP using linux-igd (<a
|
|
href="http://linux-idg.sourceforge.net/">http://linux-idg.sourceforge.net</a>).
|
|
UPnP is required by a number of popular applications including MSN
|
|
IM.</li>
|
|
</ol>
|
|
|
|
<div style="margin-left: 40px;">
|
|
<span style="font-weight: bold;">WARNING</span>:<br>
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
From a security architecture viewpoint, UPnP is a disaster. It assumes
|
|
that:<br>
|
|
|
|
<ol style="list-style-type: lower-alpha;">
|
|
<li>All local systems and their users are completely trustworthy.</li>
|
|
<li>No local system is infected with any worm or trojan.</li>
|
|
</ol>
|
|
</div>
|
|
|
|
<div style="margin-left: 40px;">
|
|
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.<br>
|
|
In short: <span style="font-weight: bold;">USE UPnP AT YOUR OWN
|
|
RISK</span>.<br>
|
|
</div>
|
|
|
|
<div style="margin-left: 40px;">
|
|
<br>
|
|
</div>
|
|
</div>
|
|
|
|
<div style="margin-left: 40px;">
|
|
<span style="font-weight: bold;">WARNING</span>:<br>
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
The linux-igd project appears to be inactive and the web site does not
|
|
display correctly on any open source browser that I've tried.<br>
|
|
<br>
|
|
Building and installing linux-igd is not for the faint of heart. You must
|
|
download the source from CVS and be prepared to do quite a bit of fiddling
|
|
with the include files from libupnp (which is required to build and/or run
|
|
linux-igd).<br>
|
|
<br>
|
|
</div>
|
|
</div>
|
|
|
|
<div style="margin-left: 40px;">
|
|
Configuring linux-igd:<br>
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
In /etc/upnpd.conf, you will want:<br>
|
|
<br>
|
|
|
|
insert_forward_rules = yes<br>
|
|
|
|
prerouting_chain_name = UPnP<br>
|
|
|
|
forward_chain_name = forwardUPnP<br>
|
|
<br>
|
|
</div>
|
|
</div>
|
|
|
|
<div style="margin-left: 40px;">
|
|
Shorewall Configuration:<br>
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
In /etc/shorewall/interfaces, you need the 'upnp' option on your external
|
|
interface.<br>
|
|
<br>
|
|
If your fw->loc policy is not ACCEPT then you need this rule:<br>
|
|
<br>
|
|
|
|
allowoutUPnP
|
|
fw loc<br>
|
|
<br>
|
|
Note: To use 'allowoutUPnP', your iptables and kernel must support the 'owner
|
|
match' feature (see the output of "shorewall check").<br>
|
|
<br>
|
|
If your loc->fw policy is not ACCEPT then you need this rule:<br>
|
|
<br>
|
|
|
|
allowinUPnP
|
|
loc fw<br>
|
|
<br>
|
|
You MUST have this rule:<br>
|
|
<br>
|
|
|
|
forwardUPnP
|
|
net loc<br>
|
|
<br>
|
|
</div>
|
|
</div>
|
|
|
|
<div style="margin-left: 40px;">
|
|
You must also ensure that you have a route to 224.0.0.0/4 on you
|
|
internal (local) interface.<br>
|
|
</div>
|
|
<ol start="2" style="list-style-type: decimal;">
|
|
<li>A new 'started' extension script has been added. The difference
|
|
between this extension script and /etc/shorewall/start is that this one
|
|
is invoked after delayed loading of the blacklist
|
|
(DELAYBLACKLISTLOAD=Yes) and after the 'shorewall' chain has been created
|
|
(thus signaling that the firewall is completely up.<br>
|
|
<br>
|
|
/etc/shorewall/started should not change the firewall configuration
|
|
directly but may do so indirectly by running /sbin/shorewall with the
|
|
'nolock' option.<br>
|
|
<br>
|
|
</li>
|
|
<li>By default, shorewall is started with the "-f" (fast) option when your
|
|
system boots. You can override that setting by setting the OPTIONS
|
|
variable in /etc/sysconfig/shorewall (SUSE/Redhat) or
|
|
/etc/default/shorewall (Debian/Bering). If neither file exists, feel free
|
|
to create one or the other.<br>
|
|
<br>
|
|
Example: If you want Shorewall to always use the config files even if
|
|
there is a saved configuration, then specify:<br>
|
|
<br>
|
|
OPTIONS=""<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall now has support for the SAME target. This change affects the
|
|
/etc/shorewall/masq and /etc/shorewall/rules file.<br>
|
|
<br>
|
|
SAME is useful when you specify multiple target IP addresses (in the
|
|
ADDRESSES column of /etc/shorewall/masq or in the DEST column of
|
|
/etc/shorewall/rules).<br>
|
|
<br>
|
|
If you use normal SNAT then multiple connections from a given local host
|
|
to hosts on the internet can be assigned different source IP addresses.
|
|
This confuses some applications that use multiple connections. To correct
|
|
this problem, prefix the list of address ranges in the ADDRESS column
|
|
with "SAME:"<br>
|
|
<br>
|
|
|
|
Example: SAME:206.124.146.176-206.124.146.180<br>
|
|
<br>
|
|
If you want each internal system to use the same IP address from the list
|
|
regardless of which internet host it is talking to then prefix the ranges
|
|
with "SAME:nodst:".<br>
|
|
<br>
|
|
|
|
Example: SAME:nodst:206.124.146.176-206.124.146.180<br>
|
|
<br>
|
|
Note that it is not possible to map port numbers when using SAME.<br>
|
|
<br>
|
|
In the rules file, when multiple connections from an internet host match
|
|
a SAME rule then all of the connections will be sent to the same internal
|
|
server. SAME rules are very similar to DNAT rules with the keyword SAME
|
|
replacing DNAT. As in the masq file, changing the port number is not
|
|
supported.<br>
|
|
<br>
|
|
</li>
|
|
<li>A "shorewall show capabilities" command has been added to report the
|
|
capabilities of your kernel and iptables.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
gateway:~# shorewall show capabilities<br>
|
|
Loading
|
|
/usr/share/shorewall/functions...<br>
|
|
Processing /etc/shorewall/params ...<br>
|
|
Processing
|
|
/etc/shorewall/shorewall.conf...<br>
|
|
Loading Modules...<br>
|
|
Shorewall has detected the following
|
|
iptables/netfilter capabilities:<br>
|
|
|
|
NAT: Available<br>
|
|
|
|
Packet Mangling: Available<br>
|
|
|
|
Multi-port Match: Available<br>
|
|
|
|
Extended Multi-port Match: Available<br>
|
|
|
|
Connection Tracking Match: Available<br>
|
|
|
|
Packet Type Match: Not available<br>
|
|
|
|
Policy Match: Available<br>
|
|
|
|
Physdev Match: Available<br>
|
|
|
|
IP range Match: Available<br>
|
|
|
|
Recent Match: Available<br>
|
|
|
|
Owner Match: Available<br>
|
|
gateway:~#<br>
|
|
<br>
|
|
</li>
|
|
<li>A "-v" option has been added to /sbin/shorewall. Currently, this option
|
|
only affects the "show log" command (e.g., "shorewall -v show log") and
|
|
the "monitor" command. In these commands, it causes the MAC address in
|
|
the log message (if any) to be displayed. As previously, when "-v" is
|
|
omitted, the MAC address is suppressed.<br>
|
|
<br>
|
|
</li>
|
|
<li>In /etc/shorewall/rules, a value of 'none' in either the SOURCE or DEST
|
|
columns now causes the rule to be ignored. This is most useful when used
|
|
with shell variables:<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
|
|
AllowFTP
|
|
$FTP_CLIENTS fw<br>
|
|
<br>
|
|
When FTP_CLIENTS is set to
|
|
'none', the above rule is ignored. Otherwise, the rule is evaluated
|
|
and generates Netfilter rules.<br>
|
|
<br>
|
|
</li>
|
|
<li>The installer now detects that it is running on a Slackware system and
|
|
adjusts the DEST and INIT variables accordingly.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><span style="font-weight: bold;">05/01/2005 Tom spoke at LinuxFest NW 2005
|
|
-- Bellingham Technical College, Bellingham Washington<br>
|
|
</span><br>
|
|
Tom's presentation was entitled "Shorewall and Native IPSEC" and is available
|
|
for download <a href="http://shorewall.net/LinuxFest.pdf">here (PDF
|
|
Format)</a>.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">04/07/2005 Shorewall 2.2.3<br>
|
|
</span><br>
|
|
Problems Corrected:<br>
|
|
</p>
|
|
<ol>
|
|
<li>If a zone is defined in /etc/shorewall/hosts using
|
|
<interface>:!<network> in the HOSTS column then startup
|
|
errors occur on "shorewall [re]start".</li>
|
|
<li>Previously, if "shorewall status" was run on a system whose kernel
|
|
lacked advanced routing support (CONFIG_IP_ADVANCED_ROUTER), then
|
|
no routing information was displayed.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>A new extension script "continue" has been added. This script is
|
|
invoked after Shorewall has set the built-in filter chains policy to
|
|
DROP, deleted any existing Netfilter rules and user chains and has
|
|
enabled existing connections. It is useful for enabling certain
|
|
communication while Shorewall is being [re]started. Be sure to delete any
|
|
rules that you add here in your /etc/shorewall/start file.</li>
|
|
<li>There has been ongoing confusion about how the
|
|
/etc/shorewall/routestopped file works. People understand how it works
|
|
with the 'shorewall stop' command but when they read that 'shorewall
|
|
restart' is logically equivalent to 'shorewall stop' followed by
|
|
'shorewall start' then they erroneously conclude that
|
|
/etc/shorewall/routestopped can be used to enable new connections during
|
|
'shorewall restart'. Up to now, it cannot -- that file is not processed
|
|
during either 'shorewall start' or 'shorewall restart'.<br>
|
|
<br>
|
|
Beginning with Shorewall version 2.2.3, /etc/shorewall/routestopped will
|
|
be processed TWICE during 'shorewall start' and during 'shorewall
|
|
restart'. It will be processed early in the command execution to add
|
|
rules allowing new connections while the command is running and it will
|
|
be processed again when the command is complete to remove the rules added
|
|
earlier.<br>
|
|
<br>
|
|
The result of this change will be that during most of [re]start, new
|
|
connections will be allowed in accordance with the contents of
|
|
/etc/shorewall/routestopped.</li>
|
|
<li>The performance of configurations with a large numbers of entries in
|
|
/etc/shorewall/maclist can be improved by setting the new MACLIST_TTL
|
|
variable in /etc/shorewall/shorewall.conf.<br>
|
|
<br>
|
|
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.<br>
|
|
<br>
|
|
When a new connection arrives from a 'maclist' interface, the packet
|
|
passes through then list of entries for that interface in
|
|
/etc/shorewall/maclist. 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 occuring 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.<br>
|
|
<br>
|
|
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.</li>
|
|
<li>You can now specify QUEUE as a policy and you can designate a common
|
|
action for QUEUE policies in /etc/shorewall/actions. This is useful for
|
|
sending packets to something like Snort Inline.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;">03/31/2005 Shorewall 2.0.17<br>
|
|
<br>
|
|
</span> Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>Invoking the 'rejNotSyn' action results in an error at startup.</li>
|
|
<li>The UDP and TCP port numbers in /usr/share/shorewall/action.AllowPCA
|
|
were reversed.</li>
|
|
<li>If a zone is defined in /etc/shorewall/hosts using <<span
|
|
style="font-style: italic;">interface</span>>:!<<span
|
|
style="font-style: italic;">network</span>> in the HOSTS column then
|
|
startup errors occur on "shorewall [re]start".<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;">03/12/2005 Shorewall 2.2.2<br>
|
|
</span> <br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>The SOURCE column in the /etc/shorewall/tcrules file now correctly
|
|
allows IP ranges (assuming that your iptables and kernel support
|
|
ranges).<br>
|
|
</li>
|
|
<li>If A is a user-defined action and you have file /etc/shorewall/A then
|
|
when that file is invoked by Shorewall during [re]start, the $TAG value
|
|
may be incorrect.</li>
|
|
<li>Previously, if an iptables command generating a logging rule failed,
|
|
the Shorewall [re]start was still successful. This error is now
|
|
considered fatal and Shorewall will be either restored from the last save
|
|
(if any) or it will be stopped.</li>
|
|
<li>The port numbers for UDP and TCP were previously reversed in the
|
|
/usr/share/shorewall/action.AllowPCA file.</li>
|
|
<li>Previously, the 'install.sh' script did not update the
|
|
/usr/share/shorewall/action.* files.</li>
|
|
<li>Previously, when an interface name appeared in the DEST column of
|
|
/etc/shorewall/tcrules, the name was not validated against the set of
|
|
defined interfaces and bridge ports.<br>
|
|
</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>The SOURCE column in the /etc/shorewall/tcrules file now allows $FW to
|
|
be optionally followed by ":" and a host/network address or address
|
|
range.</li>
|
|
<li>Shorewall now clears the output device only if it is a terminal. This
|
|
avoids ugly control sequences being placed in files when /sbin/shorewall
|
|
output is redirected.</li>
|
|
<li>The output from 'arp -na' has been added to the 'shorewall status'
|
|
display.</li>
|
|
<li>The 2.6.11 Linux kernel and iptables 1.3.0 now allow port ranges to
|
|
appear in port lists handled by "multiport match". If Shorewall detects
|
|
this capability, it will use "multiport match" for port lists containing
|
|
port ranges. Be cautioned that each port range counts for TWO ports and a
|
|
port list handled with "multiport match" can still specify a maximum of
|
|
15 ports.<br>
|
|
<br>
|
|
As always, if a port list in /etc/shorewall/rules is incompatible with
|
|
"multiport match", a separate iptables rule will be generated for each
|
|
element in the list.</li>
|
|
<li>Traditionally, the RETURN target in the 'rfc1918' file has caused
|
|
'norfc1918' processing to cease for a packet if the packet's source IP
|
|
address matches the rule. Thus, if you have:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">
|
|
SUBNETS
|
|
TARGET</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
192.168.1.0/24 RETURN</span><br>
|
|
<br>
|
|
then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though
|
|
you also have:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">
|
|
SUBNETS
|
|
TARGET</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
10.0.0.0/8 logdrop</span><br>
|
|
<br>
|
|
Setting RFC1918_STRICT=Yes in shorewall.conf will cause such traffic to
|
|
be logged and dropped since while the packet's source matches the RETURN
|
|
rule, the packet's destination matches the 'logdrop' rule.<br>
|
|
<br>
|
|
If not specified or specified as empty (e.g., RFC1918_STRICT="") then
|
|
RFC1918_STRICT=No is assumed.<br>
|
|
<br>
|
|
WARNING: RFC1918_STRICT=Yes requires that your kernel and iptables
|
|
support 'Connection Tracking' match.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><span style="font-weight: bold;">02/15/2005 Shorewall 2.2.1<br>
|
|
<br>
|
|
</span> This release rolls up the fixes for bugs found in the first 2-3 weeks
|
|
of deployment of Shorewall 2.2.<br>
|
|
</p>
|
|
<ol>
|
|
<li>The /etc/shorewall/policy file contained a misleading comment and both
|
|
that file and the /etc/shorewall/zones file lacked examples.</li>
|
|
<li>Shorewall previously used root's default umask which could cause files
|
|
in /var/lib/shorewall to be world-readable. Shorewall now uses umask
|
|
0177.</li>
|
|
<li>In log messages produced by logging a built-in action, the packet
|
|
disposition was displayed incorrectly.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
|
|
rejNotSyn:ULOG all
|
|
all
|
|
tcp<br>
|
|
<br>
|
|
produces the log message:<br>
|
|
<br>
|
|
Feb 12
|
|
23:57:08 server Shorewall:rejNotSyn:ULOG: ...<br>
|
|
<br>
|
|
rather than<br>
|
|
<br>
|
|
Feb 12
|
|
23:57:08 server Shorewall:rejNotSyn:REJECT: ...<br>
|
|
<br>
|
|
</li>
|
|
<li>The comments regarding built-in actions in
|
|
/usr/share/shorewall/actions.std have been corrected.</li>
|
|
<li>The /etc/shorewall/policy file in the LRP package was missing the
|
|
'all->all' policy.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;">02/05/2005 End of Support for Shorewall
|
|
1.4<br>
|
|
<br>
|
|
</span> Effective today, support for Shorewall 1.4 has been discontinued. See
|
|
the link at the top of this article for upgrade information.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">02/01/2005 Shorewall 2.0.16<br>
|
|
</span> <br>
|
|
This release back-ports the DROPINVALID shorewall.conf option from 2.2.0.<br>
|
|
|
|
<ol>
|
|
<li>Recent 2.6 kernels include code that evaluates TCP packets based on TCP
|
|
Window analysis. This can cause packets that were previously classified
|
|
as NEW or ESTABLISHED to be classified as INVALID.<br>
|
|
<br>
|
|
The new kernel code can be disabled by including this command in your
|
|
/etc/shorewall/init file:<br>
|
|
<br>
|
|
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
|
|
<br>
|
|
Additional kernel logging about INVALID TCP packets may be obtained by
|
|
adding this command to /etc/shorewall/init:<br>
|
|
<br>
|
|
echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
|
|
<br>
|
|
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
|
|
DROPINVALID option allows INVALID packets to be passed through the normal
|
|
rules chains by setting DROPINVALID=No.<br>
|
|
<br>
|
|
If not specified or if specified as empty (e.g., DROPINVALID="") then
|
|
DROPINVALID=Yes is assumed.</li>
|
|
</ol>
|
|
|
|
<p><span style="font-weight: bold;">02/01/2005 Shorewall 2.2.0<br>
|
|
<br>
|
|
</span> New Features:<br>
|
|
</p>
|
|
<ol>
|
|
<li>ICMP packets that are in the INVALID state are now dropped by the
|
|
Reject and Drop default actions. They do so using the new 'dropInvalid'
|
|
builtin action. An 'allowInvalid' builtin action is also provided which
|
|
accepts packets in that state.</li>
|
|
<li>The /etc/shorewall/masq file INTERFACE column now allows additional
|
|
options.<br>
|
|
<br>
|
|
Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules
|
|
defined in the /etc/shorewall/nat file. If you preceed the interface name
|
|
with a plus sign ("+") then the rule will be evaluated before one-to-one
|
|
NAT.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
+eth0<br>
|
|
+eth1:192.0.2.32/27<br>
|
|
<br>
|
|
Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an entry by
|
|
following the interface name by ":" but no digit.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
eth0:<br>
|
|
eth1::192.0.2.32/27<br>
|
|
+eth3:<br>
|
|
<br>
|
|
</li>
|
|
<li>Similar to 2), the /etc/shorewall/nat file INTERFACE column now allows
|
|
you to override the setting of ADD_IP_ALIASES=Yes by following the
|
|
interface name with ":" but no digit.</li>
|
|
<li>All configuration files in the Shorewall distribution with the
|
|
exception of shorewall.conf are now empty. In particular, the
|
|
/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos files
|
|
now have no active entries. Hopefully this will stop the questions on the
|
|
support and development lists regarding why the default entries are the
|
|
way they are.</li>
|
|
<li>Previously, including a log level (and optionally a log tag) on a rule
|
|
that specified a user-defined (or Shorewall-defined) action would log all
|
|
traffic passed to the action. Beginning with this release, specifying a
|
|
log level in a rule that specifies a user- or Shorewall-defined action
|
|
will cause each rule in the action to be logged with the specified level
|
|
(and tag).<br>
|
|
<br>
|
|
The extent to which logging of action rules occurs is goverend by the
|
|
following:</li>
|
|
<li style="list-style: none"><ul>
|
|
<li>When you invoke an action and specify a log level, only those rules
|
|
in the action that have no log level will be changed to log at the
|
|
level specified at the action invocation.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/action.foo:<br>
|
|
<br>
|
|
ACCEPT - -
|
|
tcp 22<br>
|
|
bar:info<br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
foo:debug fw net<br>
|
|
<br>
|
|
Logging in the invoked 'foo' action will be:<br>
|
|
<br>
|
|
ACCEPT:debug -
|
|
- tcp 22<br>
|
|
bar:info<br>
|
|
<br>
|
|
</li>
|
|
<li>If you follow the log level with "!" then logging will be at that
|
|
level for all rules recursively invoked by the action<br>
|
|
<br>
|
|
Example: /etc/shorewall/action.foo:<br>
|
|
<br>
|
|
<b>Update:</b> I've been informed by Mandrake Development that this
|
|
problem has been corrected in Mandrake 10.0 Final (the problem still
|
|
exists in the 10.0 Community release).<br>
|
|
ACCEPT - -
|
|
tcp 22<br>
|
|
bar:info<br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
foo:debug! fw net<br>
|
|
<br>
|
|
Logging in the invoke 'foo' action will be:<br>
|
|
<br>
|
|
ACCEPT:debug -
|
|
- tcp 22<br>
|
|
bar:debug!<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ol>
|
|
|
|
<div style="margin-left: 40px;">
|
|
This change has an effect on extension scripts used with user-defined
|
|
actions. If you define an action 'acton' and you have an /etc/shorewall/acton
|
|
script then when that script is invoked, the following three variables will
|
|
be set for use by the script:<br>
|
|
<br>
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
$CHAIN = the name of the chain where your rules are to be placed. When
|
|
logging is used on an action invocation, Shorewall creates a chain with a
|
|
slightly different name from the action itself.<br>
|
|
$LEVEL = Log level. If empty, no logging was specified.<br>
|
|
$TAG = Log Tag.<br>
|
|
<br>
|
|
</div>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
acton:info:test<br>
|
|
<br>
|
|
Your /etc/shorewall/acton file will be run with:<br>
|
|
<br>
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
$CHAIN="%acton1<br>
|
|
$LEVEL="info"<br>
|
|
$TAG="test"<br>
|
|
</div>
|
|
</div>
|
|
<br>
|
|
|
|
<ol start="6">
|
|
<li>The /etc/shorewall/startup_disabled file is no longer created when
|
|
Shorewall is first installed. Rather, the variable STARTUP_ENABLED is set
|
|
to 'No' in /etc/shorewall/shorewall.conf. In order to get Shorewall to
|
|
start, that variable's value must be set to 'Yes'. This change
|
|
accomplishes two things:</li>
|
|
<li style="list-style: none"><ul>
|
|
<li>It prevents Shorewall from being started prematurely by the user's
|
|
initialization scripts.</li>
|
|
<li>It causes /etc/shorewall/shorewall.conf to be modified so that it
|
|
won't be replaced by upgrades using RPM.<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>Support has been added for the 2.6 Kernel IPSEC implementation. To use
|
|
this support, you must have installed the IPSEC policy match patch and
|
|
the four IPSEC/Netfilter patches from Patch-0-Matic-ng. The policy match
|
|
patch affects both your kernel and iptables. There are two ways to
|
|
specify that IPSEC is to be used when communicating with a set of hosts;
|
|
both methods involve the new /etc/shorewall/ipsec file:</li>
|
|
<li style="list-style: none"><ol style="list-style-type: lower-alpha;">
|
|
<li>If encrypted communication is used with all hosts in a zone, then
|
|
you can designate the zone as an "ipsec" zone by placing 'Yes" in the
|
|
IPSEC ONLY column in /etc/shorewall/ipsec:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">#ZONE
|
|
IPSEC OPTIONS ...</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">#
|
|
ONLY</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">vpn
|
|
Yes</span><br>
|
|
<br>
|
|
The hosts in the zone (if any) must be specified in
|
|
/etc/shorewall/hosts but you do not need to specify the 'ipsec'
|
|
option on the entries in that file (see below). Dynamic zones
|
|
involving IPSEC must use that technique.<br>
|
|
<br>
|
|
Example:Under 2.4 Kernel FreeS/Wan:<br>
|
|
<br>
|
|
/etc/shorewall/zones:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
Net The big bad Internet</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">vpn
|
|
VPN Remote Network</span><br>
|
|
<br>
|
|
/etc/shorewall/interfaces:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
eth0 ...</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">vpn
|
|
ipsec0 ...</span><br>
|
|
<br>
|
|
Under 2.6 Kernel with this new support:<br>
|
|
<br>
|
|
/etc/shorewall/zones:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
Net The big bad Internet</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">vpn
|
|
VPN Remote Network</span><br>
|
|
<br>
|
|
/etc/shorewall/interfaces:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
eth0 ...</span><br>
|
|
<br>
|
|
/etc/shorewall/hosts:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">vpn
|
|
eth0:0.0.0.0/0</span><br>
|
|
<br>
|
|
/etc/shorewall/ipsec<br>
|
|
<br>
|
|
<span style="font-family: monospace;">vpn Yes<br>
|
|
<br>
|
|
</span></li>
|
|
<li>If only part of the hosts in a zone require encrypted
|
|
communication, you may use of the new 'ipsec' option in
|
|
/etc/shorewall/hosts to designate those hosts.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
Under 2.4 Kernel FreeS/Wan:<br>
|
|
<br>
|
|
/etc/shorewall/zones:<br>
|
|
|
|
<pre>net Net The big bad Internet<br>
|
|
loc Local Extended local zone</pre>
|
|
/etc/shorewall/interfaces:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
eth0 ...</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">loc
|
|
eth1 ...</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">loc
|
|
ipsec0 ...</span><br>
|
|
<br>
|
|
Under 2.6 Kernel with this new support:<br>
|
|
<br>
|
|
/etc/shorewall/zones:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
Net The big bad
|
|
Internet</span><br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">vpn
|
|
VPN Remote Network</span><br>
|
|
<br>
|
|
/etc/shorewall/interfaces:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">net
|
|
eth0 ...</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">loc
|
|
eth1 ...</span><br>
|
|
<br>
|
|
/etc/shorewall/hosts:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">vpn
|
|
eth0:0.0.0.0/0 ipsec,...</span> </li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
|
|
<div style="margin-left: 40px;">
|
|
Regardless of which technique you choose, you can specify additional SA
|
|
options for the zone in the /etc/shorewall/ipsec entry.<br>
|
|
<br>
|
|
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the input-output,
|
|
input and output characteristics of the security associations to be used to
|
|
decrypt (input) or encrypt (output) traffic to/from the zone.<br>
|
|
<br>
|
|
The available options are:<br>
|
|
</div>
|
|
|
|
<div style="margin-left: 2em">
|
|
<ul>
|
|
<li>reqid[!]=<number> where <number> is specified using
|
|
setkey(8) using the 'unique:<number>' option for the SPD level.</li>
|
|
<li>spi[!]=<number> where <number> is the SPI of the SA. Since
|
|
different SAs are used to encrypt and decrypt traffic, this option should
|
|
only be listed in the IN OPTIONS and OUT OPTIONS columns.</li>
|
|
<li>proto[!]=ah|esp|ipcomp</li>
|
|
<li>mss=<number> (sets the MSS value in TCP SYN packets and is not
|
|
related to policy matching)</li>
|
|
<li>mode[!]=transport|tunnel</li>
|
|
<li>tunnel-src[!]=<address>[/<mask>] (only available with
|
|
mode=tunnel)</li>
|
|
<li>tunnel-dst[!]=<address>[/<mask>] (only available with
|
|
mode=tunnel). Because tunnel source and destination are dependent on the
|
|
direction of the traffic, these options should only appear in the IN
|
|
OPTIONS and OUT OPTIONS columns.</li>
|
|
<li>strict (if specified, packets must match all policies; policies
|
|
are delimited by 'next').</li>
|
|
<li>next (only available with strict)</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div style="margin-left: 40px;">
|
|
Examples:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">#ZONE IPSEC
|
|
OPTIONS
|
|
IN
|
|
OUT</span><br style="font-family: monospace;">
|
|
<span
|
|
style="font-family: monospace;">#
|
|
ONLY
|
|
|
|
OPTIONS OPTIONS</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">vpn
|
|
Yes mode=tunnel,proto=esp
|
|
spi=1000 spi=1001</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">loc
|
|
No reqid=44,mode=transport</span><br>
|
|
<br>
|
|
The /etc/shorewall/masq file has a new IPSEC column added. If you specify Yes
|
|
or yes in that column then the unencrypted packets will have their source
|
|
address changed. Otherwise, the unencrypted packets will not have their
|
|
source addresses changed. This column may also contain a comma-separated list
|
|
of the options specified above in which case only those packets that will be
|
|
encrypted by an SA matching the given options will have their source address
|
|
changed.<br>
|
|
</div>
|
|
<ol start="8">
|
|
<li>To improve interoperability, tunnels of type 'ipsec' no longer enforce
|
|
the use of source port 500 for ISAKMP and OpenVPN tunnels no longer
|
|
enforce use of the specified port as both the source and destination
|
|
ports.</li>
|
|
<li>A new 'allowBcast' builtin action has been added -- it silently allows
|
|
broadcasts and multicasts.</li>
|
|
<li>The -c option in /sbin/shorewall commands is now deprecated. The
|
|
commands where -c was previously allowed now permit you to specify a
|
|
configuration directory after the command:<br>
|
|
<br>
|
|
shorewall check [
|
|
<configuration-directory> ]<br>
|
|
shorewall restart [
|
|
<configuration-directory> ]<br>
|
|
shorewall start [
|
|
<configuration-directory> ]<br>
|
|
<br>
|
|
</li>
|
|
<li>Normally, when SNAT or MASQUERADE is applied to a tcp or udp
|
|
connection, Netfilter attempts to retain the source port number. If it
|
|
has to change to port number to avoid <source
|
|
address>,<source port> conflicts, it tries to do so within port
|
|
ranges ( < 512, 512-1023, and > 1023). You may now specify an
|
|
explicit range of source ports to be used by following the address or
|
|
address range (if any) in the ADDRESS column with ":" and a port range in
|
|
the format <low-port>-<high-port>. You must specify either
|
|
"tcp" or "udp" in the PROTO column.<br>
|
|
<br>
|
|
Examples 1 -- MASQUERADE with tcp source ports 4000-5000:<br>
|
|
<br>
|
|
<span style="font-family: monospace;"> #INTERFACE
|
|
SUBNET
|
|
ADDRESS PROTO</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth0 192.168.1.0/24
|
|
:4000-5000 tcp</span><br
|
|
style="font-family: monospace;">
|
|
<br>
|
|
Example 2 -- SNAT with udp source ports 7000-8000:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">#INTERFACE
|
|
SUBNET
|
|
ADDRESS
|
|
|
|
PROTO</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth0
|
|
10.0.0.0/8
|
|
192.0.2.44:7000-8000 udp<br>
|
|
<br>
|
|
</span></li>
|
|
<li>You may now account by user/group ID for outbound traffic from the
|
|
firewall itself with entries in /etc/shorewall/accounting. Such
|
|
accounting rules must be placed in the OUTPUT chain. See the comments at
|
|
the top of /etc/shorewall/accounting for details.</li>
|
|
<li>Shorewall now verifies that your kernel and iptables have physdev match
|
|
support if BRIDGING=Yes in shorewall.conf.</li>
|
|
<li>Beginning with this release, if your kernel and iptables have iprange
|
|
match support (see the output from "shorewall check"), then with the
|
|
exception of the /etc/shorewall/netmap file, anywhere that a network
|
|
address may appear an IP address range of the form <low
|
|
address>-<high address> may also appear.</li>
|
|
<li>Support has been added for the iptables CLASSIFY target. That target
|
|
allows you to classify packets for traffic shaping directly rather than
|
|
indirectly through fwmark. Simply enter the <major>:<minor>
|
|
classification in the first column of /etc/shorewall/tcrules:<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">#MARK/
|
|
SOURCE
|
|
DEST PROTO
|
|
PORT(S)</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">#CLASSIFY</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">1:30
|
|
-
|
|
eth0 tcp
|
|
25</span><br>
|
|
<br>
|
|
Note that when using this form of rule, it is acceptable to include the
|
|
name of an interface in the DEST column.<br>
|
|
<br>
|
|
Marking using the CLASSIFY target always occurs in the POSTROUTING chain
|
|
of the mangle table and is not affected by the setting of
|
|
MARK_IN_FORWARD_CHAIN in shorewall.conf.</li>
|
|
<li>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
|
|
/etc/shorewall/nat and /etc/shorewall/masq are processed then they 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. A new RETAIN_ALIASES option has
|
|
been added to shorewall.conf; when this option 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".</li>
|
|
<li>Users with a large black list (from /etc/shorewall/blacklist) may want
|
|
to set the new DELAYBLACKLISTLOAD option in shorewall.conf. 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".</li>
|
|
<li>Using the default LOGFORMAT, chain names longer than 11 characters
|
|
(such as in user-defined actions) may result in log prefix truncation. A
|
|
new shorewall.conf action LOGTAGONLY has been added to deal with
|
|
this problem. When LOGTAGONLY=Yes, logging rules that specify a log tag
|
|
will substitute the tag for the chain name in the log prefix.<br>
|
|
<br>
|
|
Example -- file /etc/shorewall/action.thisisaverylogactionname:<br>
|
|
<br>
|
|
Rule:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">DROP:info:ftp
|
|
0.0.0.0/0 0.0.0.0/0
|
|
tcp 21</span><br>
|
|
<br>
|
|
Log prefix with LOGTAGONLY=No:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">Shorewall:thisisaverylongacti</span><br>
|
|
<br>
|
|
Log prefix with LOGTAGONLY=Yes:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">Shorewall:ftp:DROP</span><br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall now resets the 'accept_source_route' flag for all interfaces.
|
|
If you wish to accept source routing on an interface, you must specify
|
|
the new 'sourceroute' interface option in /etc/shorewall/interfaces.</li>
|
|
<li>The default Drop and Reject actions now invoke the new standard action
|
|
'AllowICMPs'. This new action accepts critical ICMP types:<br>
|
|
<br>
|
|
Type 3 code 4 (fragmentation needed)<br>
|
|
Type 11 (TTL
|
|
exceeded)<br>
|
|
<br>
|
|
</li>
|
|
<li>Explicit control over the kernel's Martian logging is now provided
|
|
using the new 'logmartians' interface option. If you include
|
|
'logmartians' in the interface option list then logging of Martian
|
|
packets on will be enabled on the specified interface. If you wish to
|
|
globally enable martian logging, you can set LOG_MARTIANS=Yes in
|
|
shorewall.conf.</li>
|
|
<li>You may now cause Shorewall to use the '--set-mss' option of the TCPMSS
|
|
target. In other words, you can cause Shorewall to set the MSS field of
|
|
SYN packets passing through the firewall to the value you specify. This
|
|
feature extends the existing CLAMPMSS option in
|
|
/etc/shorewall/shorewall.conf by allowing that option to have a numeric
|
|
value as well as the values "Yes" and "No".<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
CLAMPMSS=1400<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall now includes support for the ipp2p match facility. This is a
|
|
departure from my usual policy in that the ipp2p match facility is
|
|
included in Patch-O-Matic-NG and is unlikely to ever be included in the
|
|
kernel.org source tree. Questions about how to install the patch or how
|
|
to build your kernel and/or iptables should not be posted on the
|
|
Shorewall mailing lists.<br>
|
|
<br>
|
|
In the following files, the "PROTO" or "PROTOCOL" column may contain
|
|
"ipp2p":<br>
|
|
<br>
|
|
/etc/shorewall/rules<br>
|
|
/etc/shorewall/tcrules<br>
|
|
/etc/shorewall/accounting<br>
|
|
<br>
|
|
When the PROTO or PROTOCOL column contains "ipp2p" then the DEST PORT(S)
|
|
or PORT(S) column may contain a recognized ipp2p option; for a list of
|
|
the options and their meaning, at a root prompt:<br>
|
|
<br>
|
|
iptables -m ipp2p --help<br>
|
|
<br>
|
|
You must not include the leading "--" on the option; Shorewall will
|
|
supply those characters for you. If you do not include an option then
|
|
"ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").</li>
|
|
<li>Shorewall now has support for the CONNMARK target from iptables. See
|
|
the /etc/shorewall/tcrules file for details.</li>
|
|
<li>A new debugging option LOGALLNEW has been added to shorewall.conf. When
|
|
set to a log level, this option causes Shorewall to generaate a logging
|
|
rule as the first rule in each builtin chain.<br>
|
|
<br>
|
|
- The table name is used as the chain name in the log
|
|
prefix.<br>
|
|
- The chain name is used as the target in the log
|
|
prefix.<br>
|
|
<br>
|
|
Example: Using the default LOGFORMAT, the log prefix for logging from the
|
|
nat table's PREROUTING chain is:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">Shorewall:nat:PREROUTING</span><br>
|
|
<br>
|
|
IMPORTANT: There is no rate limiting on these logging rules so 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.<br>
|
|
<br>
|
|
DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL BE SENT
|
|
TO ANOTHER SYSTEM.<br>
|
|
<br>
|
|
</li>
|
|
<li>The SUBNET column in /etc/shorewall/rfc1918 has been renamed SUBNETS
|
|
and it is now possible to specify a list of addresses in that column.</li>
|
|
<li>The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).</li>
|
|
<li>For consistency, the CLIENT PORT(S) column in the tcrules file has been
|
|
renamed SOURCE PORT(S).</li>
|
|
<li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now shown in
|
|
the output of "shorewall status".</li>
|
|
<li>A new IPTABLES option has been added to shorewall.conf. IPTABLES can be
|
|
used to designate the iptables executable to be used by Shorewall. If not
|
|
specified, the iptables executable determined by the PATH setting is
|
|
used.</li>
|
|
<li>You can now use the "shorewall show zones" command to display the
|
|
current contents of the zones. This is particularly useful if you use
|
|
dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">ursa:/etc/shorewall # shorewall show
|
|
zones</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST
|
|
2004</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> </span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> loc</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth0:192.168.1.0/24</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth1:1.2.3.4</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
net </span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth0:0.0.0.0/0</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> WiFi</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> sec</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> </span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
ursa:/etc/shorewall #</span><br>
|
|
<br>
|
|
</li>
|
|
<li>Variable expansion may now be used with the INCLUDE directive.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/params<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">FILE=/etc/foo/bar</span><br>
|
|
<br>
|
|
Any other config file:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">INCLUDE $FILE</span><br>
|
|
<br>
|
|
</li>
|
|
<li>The output of "shorewall status" now includes the results of "ip -stat
|
|
link ls". This helps diagnose performance problems caused by link
|
|
errors.</li>
|
|
<li>Previously, when rate-limiting was specified in /etc/shorewall/policy
|
|
(LIMIT:BURST column), any traffic which exceeded the specified rate was
|
|
silently dropped. Now, if a log level is given in the entry (LEVEL
|
|
column) then drops are logged at that level at a rate of 5/min with a
|
|
burst of 5.</li>
|
|
<li>Recent 2.6 kernels include code that evaluates TCP packets based on TCP
|
|
Window analysis. This can cause packets that were previously classified
|
|
as NEW or ESTABLISHED to be classified as INVALID.<br>
|
|
<br>
|
|
The new kernel code can be disabled by including this command in your
|
|
/etc/shorewall/init file:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">echo 1 >
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal</span><br>
|
|
<br>
|
|
Additional kernel logging about INVALID TCP packets may be obtained by
|
|
adding this command to /etc/shorewall/init:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">echo 1 >
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid</span><br>
|
|
<br>
|
|
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
|
|
DROPINVALID option allows INVALID packets to be passed through the normal
|
|
rules chains by setting DROPINVALID=No.<br>
|
|
<br>
|
|
If not specified or if specified as empty (e.g., DROPINVALID="") then
|
|
DROPINVALID=Yes is assumed.<br>
|
|
<br>
|
|
</li>
|
|
<li>The "shorewall add" and "shorewall delete" commands now accept a list
|
|
of hosts to add or delete.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">shorewall add
|
|
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> shorewall delete
|
|
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br>
|
|
<br>
|
|
The above commands may also be written:<br>
|
|
<br>
|
|
<span style="font-family: monospace;">shorewall add
|
|
eth1:1.2.3.4,2.3.4.5 z12</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;"> shorewall delete
|
|
eth1:1.2.3.4,2.3.4.5 z12</span><br>
|
|
<br>
|
|
</li>
|
|
<li>TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel type.
|
|
OpenVPN entries in /etc/shorewall/tunnels have this format:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">openvpn[:{tcp|udp}][:<port>]
|
|
<zone>
|
|
<gateway></span><br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
<span
|
|
style="font-family: monospace;">openvpn:tcp
|
|
net 1.2.3.4
|
|
# TCP tunnel on port 1194</span><br style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
openvpn:3344 net
|
|
1.2.3.4 # UDP on port 3344</span><br
|
|
style="font-family: monospace;">
|
|
<span style="font-family: monospace;">
|
|
openvpn:tcp:4455 net
|
|
1.2.3.4 # TCP on port 4455</span><br>
|
|
<br>
|
|
</li>
|
|
<li>A new 'ipsecvpn' script is included in the tarball and in the RPM. The
|
|
RPM installs the file in the Documentation directory
|
|
(/usr/share/doc/packages/shorewall-2.2.0-0RC1).<br>
|
|
<br>
|
|
This script is intended for use on Roadwarrior laptops for establishing
|
|
an IPSEC SA to/from remote networks. The script has some limitations:</li>
|
|
</ol>
|
|
|
|
<div style="margin-left: 2em">
|
|
<ul>
|
|
<li>Only one instance of the script may be used at a time.</li>
|
|
<li>Only the first SPD accessed will be instantiated at the remote gateway.
|
|
So while the script creates SPDs to/from the remote gateway and each
|
|
network listed in the NETWORKS setting at the front of the script, only
|
|
one of these may be used at a time.</li>
|
|
</ul>
|
|
</div>
|
|
<ol start="39">
|
|
<li>The output of "shorewall status" now lists the loaded netfilter kernel
|
|
modules.</li>
|
|
<li>The range of UDP ports opened by the AllowTrcrt action has been
|
|
increased to 33434:33524.</li>
|
|
<li>The IANA has recently registered port 1194 for use by OpenVPN. In
|
|
previous versions of Shorewall (and OpenVPN), the default port was 5000
|
|
but has been changed to 1194 to conform to the new OpenVPN default.</li>
|
|
</ol>
|
|
|
|
<p><span style="font-weight: bold;">01/17/2005 - Shorewall 2.2.0 RC5<br>
|
|
<br>
|
|
</span> Problems Corrected:<br>
|
|
</p>
|
|
<ol>
|
|
<li>The AllowTrcrt action has been changed to allow up to 30 hops (same as
|
|
default for 'traceroute'). Previously, the action was documented as
|
|
allowing 20 hops but actually only allowed for 6 hops.<br>
|
|
</li>
|
|
<li>Using some lightweight shells, valid entries in /etc/shorewall/ecn
|
|
produce startup errors.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>A new AllowInvalid standard built-in action has been added. This action
|
|
accepts packets that are in the INVALID connection-tracking state.</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="Mirrors"></a>01/16/2005 - New
|
|
Shorewall Mirrors<br>
|
|
<br>
|
|
</span> Thanks to Lorenzo Martignoni and Nick Slikey, there are now Shorewall
|
|
<a href="shorewall_mirrors.htm">mirrors</a> in Milan Italy and in Austin
|
|
Texas. Thanks Lorenzo and Nick!<br>
|
|
<span style="font-weight: bold;"><br>
|
|
<a name="2_0_15"></a>01/12/2005 - Shorewall 2.0.15<br>
|
|
</span> <br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>The range of ports opened by the AllowTrcrt action has been expanded to
|
|
33434:33524 to allow for a maximum of 30 hops.</li>
|
|
<li>Code mis-ported from 2.2.0 in release 2.0.14 caused the following error
|
|
during "shorewall start" where SYN rate-limiting is present in
|
|
/etc/shorewall/policy:<br>
|
|
<br>
|
|
Bad argument `DROP'<br>
|
|
Try `iptables -h' or 'iptables --help' for
|
|
more information.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_2_0_RC4"></a>01/06/2005 -
|
|
Shorewall 2.2.0 RC4<br>
|
|
</span> <br>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>A listing of loaded iptables kernel modules is now included in the
|
|
output of "shorewall status".<br>
|
|
</li>
|
|
</ol>
|
|
Problems Corrected.<br>
|
|
|
|
<ol>
|
|
<li>Several problems associated with processing the IPSEC colummn in
|
|
/etc/shorewall/masq have been corrected.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_0_14"></a>01/03/2005 - Shorewall
|
|
2.0.14<br>
|
|
</span> <br>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>Previously, when rate-limiting was specified in /etc/shorewall/policy
|
|
(LIMIT:BURST column), any traffic which exceeded the specified rate was
|
|
silently dropped. Now, if a log level is given in the entry (LEVEL
|
|
column) then drops are logged at that level at a rate of 5/min with a
|
|
burst of 5.<br>
|
|
</li>
|
|
</ol>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>A typo in the /etc/shorewall/interfaces file has been fixed.</li>
|
|
<li>"bad variable" error messages occurring during "shorewall stop" and
|
|
"shorewall clear" have been eliminated.</li>
|
|
<li>A misleading typo in /etc/shorewall/tunnels has been corrected. The
|
|
TYPE column for an IPIP tunnel should contain "ipip" rather than "ip".<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="MandrakeRPMS"></a>12/31/2004 -
|
|
Mandrake-specific RPMs available<br>
|
|
<br>
|
|
</span> Jack Coates has generously volunteered to provide Shorewall RPMs for
|
|
use under Mandrake. You can download Jack's RPMs from <a target="_top"
|
|
href="http://www.monkeynoodle.org/tmp/">http://www.monkeynoodle.org/tmp/</a><br>
|
|
<br>
|
|
<span style="font-weight: bold;"><a name="Redhat_Fedora"></a>12/31/2004 -
|
|
Redhat/Fedora-specific RPMs available<br>
|
|
</span> <br>
|
|
Simon Matter has graciously volunteered to provide RPMs tailored for Redhat
|
|
and Fedora. You can download Simon's RPMs from <a target="_top"
|
|
href="http://www.invoca.ch/pub/packages/shorewall/">http://www.invoca.ch/pub/packages/shorewall/</a><br>
|
|
<br>
|
|
Thanks, Simon!<br>
|
|
<br>
|
|
<span style="font-weight: bold;"><a name="2_2_0_RC3"></a>12/30/2004 -
|
|
Shorewall 2.2.0 RC3<br>
|
|
</span> <br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>The following error message could appear during "shorewall stop" or
|
|
"shorewall clear":<br>
|
|
<br>
|
|
|
|
local: lo:: bad variable name<br>
|
|
<br>
|
|
</li>
|
|
<li>The rate limiting example in /etc/shorewall/rules has been changed to
|
|
use the RATE LIMIT column.</li>
|
|
<li>Entries in /etc/shorewall/masq with the INTERFACE column containing
|
|
<ifname>:: (e.g., "eth0::") would generate a progress message but
|
|
would not generate an iptables rule.</li>
|
|
<li>A misleading typo in /etc/shorewall/tunnels has been corrected.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><br>
|
|
</p>
|
|
|
|
<p><span style="font-weight: bold;">12/24/2004 - Shorewall 2.2.0 RC2<br>
|
|
<br>
|
|
</span> New Features:<br>
|
|
</p>
|
|
<ol>
|
|
<li>By popular demand, the default port for Open VPN tunnels is now 1194
|
|
(the IANA-reserved port number for Open VPN).</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_2_0_RC1"></a>12/19/2004 -
|
|
Shorewall 2.2.0 RC1<br>
|
|
<br>
|
|
</span> Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>The syntax of the add and delete command has been clarified in the help
|
|
summary produced by /sbin/shorewall.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel type.
|
|
OpenVPN entries in /etc/shorewall/tunnels have this format:<br>
|
|
<br>
|
|
openvpn[:{tcp|udp}][:<port>]
|
|
<zone> <gateway><br>
|
|
<br>
|
|
Examples:<br>
|
|
|
|
<pre> openvpn:tcp net 1.2.3.4 # TCP tunnel on port 5000<br>
|
|
openvpn:3344 net 1.2.3.4 # UDP on port 3344<br>
|
|
openvpn:tcp:4455 net 1.2.3.4 # TCP on port 4455</pre>
|
|
</li>
|
|
<li>A new 'ipsecvpn' script is included in the tarball and in the RPM. The
|
|
RPM installs the file in the Documentation directory
|
|
(/usr/share/doc/packages/shorewall-2.2.0-0RC1).<br>
|
|
<br>
|
|
This script is intended for use on Roadwarrior laptops for establishing
|
|
an IPSEC SA to/from remote networks. The script has some limitations:<br>
|
|
<br>
|
|
- Only one instance of the script may be used at a
|
|
time.<br>
|
|
- Only the first SPD accessed will be instantiated at
|
|
the remote gateway. So while the script creates SPDs to/from the remote
|
|
gateway and each network listed in the NETWORKS setting at the front of
|
|
the script, only one of these may be used at a time.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_2_0_Beta8"></a>12/11/2004 -
|
|
Shorewall 2.2.0 Beta 8<br>
|
|
<br>
|
|
</span> Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>A typo in the /etc/shorewall/interfaces file has been corrected.</li>
|
|
<li>Previously, the "add" and "delete" commands were generating incorrect
|
|
policy matches when policy match support was available.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>Recent 2.6 kernels include code that evaluates TCP packets based on TCP
|
|
Window analysis. This can cause packets that were previously classified
|
|
as NEW or ESTABLISHED to be classified as INVALID.<br>
|
|
<br>
|
|
The new kernel code can be disabled by including this command in your
|
|
/etc/shorewall/init file:<br>
|
|
<br>
|
|
echo 1 >
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
|
|
<br>
|
|
Additional kernel logging about INVALID TCP packets may be obtained by
|
|
adding this command to /etc/shorewall/init:<br>
|
|
<br>
|
|
echo 1 >
|
|
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
|
|
<br>
|
|
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
|
|
DROPINVALID option allows INVALID packets to be passed through the normal
|
|
rules chains by setting DROPINVALID=No.<br>
|
|
<br>
|
|
If not specified or if specified as empty (e.g., DROPINVALID="") then
|
|
DROPINVALID=Yes is assumed.<br>
|
|
<br>
|
|
</li>
|
|
<li>The "shorewall add" and "shorewall delete" commands now accept a list
|
|
of hosts to add or delete.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
shorewall add eth1:1.2.3.4 eth1:2.3.4.5 z12<br>
|
|
shorewall delete eth1:1.2.3.4 eth1:2.3.4.5 z12<br>
|
|
<br>
|
|
The above commands may also be written:<br>
|
|
<br>
|
|
shorewall add eth1:1.2.3.4,2.3.4.5 z12<br>
|
|
shorewall delete eth1:1.2.3.4,2.3.4.5 z12<br>
|
|
<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_2_0_Beta7"></a>12/04/2004 -
|
|
Shorewall 2.2.0 Beta 7<br>
|
|
</span> <br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>The "shorewall add" and "shorewall delete" commands now work in a
|
|
bridged environment. The syntax is:<br>
|
|
<br>
|
|
shorewall
|
|
add <interface>[:<port>]:<address> <zone><br>
|
|
shorewall
|
|
delete <interface>[:<port>]:<address> <zone><br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
shorewall
|
|
add br0:eth2:192.168.1.3 OK<br>
|
|
shorewall
|
|
delete br0:eth2:192.168.1.3 OK<br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, "shorewall save" created an out-of-sequence restore script.
|
|
The commands saved in the user's /etc/shorewall/start script were
|
|
executed prior to the Netfilter configuration being restored. This has
|
|
been corrected so that "shorewall save" now places those commands at the
|
|
end of the script.<br>
|
|
<br>
|
|
To accomplish this change, the "restore base" file
|
|
(/var/lib/shorewall/restore-base) has been split into two files:<br>
|
|
<br>
|
|
/var/lib/shorewall/restore-base -- commands to be executed before
|
|
Netfilter the configuration is restored.<br>
|
|
<br>
|
|
/var/lib/shorewall/restore-tail -- commands to be executed after the
|
|
Netfilter configuration is restored.<br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, traffic from the firewall to a dynamic zone member host did
|
|
not need to match the interface specified when the host was added to the
|
|
zone. For example, if eth0:1.2.3.4 is added to dynamic zone Z then
|
|
traffic out of any firewall interface to 1.2.3.4 will obey the fw->Z
|
|
policies and rules. This has been corrected.</li>
|
|
<li>Shorewall uses the temporary chain 'fooX1234' to probe iptables for
|
|
detrmining which features are supported. Previously, if that chain
|
|
happened to exist when Shorewall was run, capabilities were
|
|
mis-detected.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>You can now use the "shorewall show zones" command to display the
|
|
current contents of the zones. This is particularly useful if you use
|
|
dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
ursa:/etc/shorewall #
|
|
shorewall show zones<br>
|
|
Shorewall-2.2.0-Beta7 Zones at
|
|
ursa - Sat Nov 27 11:18:25 PST 2004<br>
|
|
<br>
|
|
loc<br>
|
|
|
|
eth0:192.168.1.0/24<br>
|
|
|
|
eth1:1.2.3.4<br>
|
|
net<br>
|
|
|
|
eth0:0.0.0.0/0<br>
|
|
WiFi<br>
|
|
|
|
eth1:0.0.0.0/0<br>
|
|
sec<br>
|
|
|
|
eth1:0.0.0.0/0<br>
|
|
<br>
|
|
ursa:/etc/shorewall #<br>
|
|
<br>
|
|
</li>
|
|
<li>Variable expansion may now be used with the INCLUDE directive.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/params<br>
|
|
<br>
|
|
|
|
FILE=/etc/foo/bar<br>
|
|
<br>
|
|
Any other config file:<br>
|
|
<br>
|
|
|
|
INCLUDE $FILE<br>
|
|
<br>
|
|
</li>
|
|
<li>The output of "shorewall status" now includes the results of "ip -stat
|
|
link ls". This helps diagnose performance problems caused by link
|
|
errors.</li>
|
|
<li>Previously, when rate-limiting was specified in /etc/shorewall/policy
|
|
(LIMIT:BURST column), any traffic which exceeded the specified rate was
|
|
silently dropped. Now, if a log<br>
|
|
level is given in the entry (LEVEL column) then drops are logged at that
|
|
level at a rate of 5/min with a burst of 5.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_0_13"></a>12/02/2004 - Shorewall
|
|
2.0.13<br>
|
|
<br>
|
|
</span> Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>A typo in /usr/share/shorewall/firewall caused the "shorewall add" to
|
|
issue an error message:<br>
|
|
|
|
<pre class="programlisting">/usr/share/shorewall/firewall: line 1: match_destination_hosts: command not found</pre>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_0_12"></a>12/01/2004 - Shorewall
|
|
2.0.12<br>
|
|
</span> <br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>A typo in shorewall.conf (NETNOTSYN) has been corrected.</li>
|
|
<li>The "shorewall add" and "shorewall delete" commands now work in a
|
|
bridged environment. The syntax is:<br>
|
|
<br>
|
|
shorewall add
|
|
<interface>[:<bridge port>][:<address>] <zone><br>
|
|
shorewall delete
|
|
<interface>[:<bridge port>][:<address>] <zone><br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
shorewall add br0:eth2:192.168.1.3 OK<br>
|
|
shorewall delete br0:eth2:192.168.1.3
|
|
OK<br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, "shorewall save" created an out-of-sequence restore script.
|
|
The commands saved in the user's /etc/shorewall/start script were
|
|
executed prior to the Netfilter configuration being restored. This has
|
|
been corrected so that "shorewall save" now places those commands at the
|
|
end of the script.<br>
|
|
<br>
|
|
To accomplish this change, the "restore base" file
|
|
(/var/lib/shorewall/restore-base) has been split into two files:<br>
|
|
<br>
|
|
/var/lib/shorewall/restore-base -- commands to be executed
|
|
before the Netfilter configuration is restored.<br>
|
|
<br>
|
|
/var/lib/shorewall/restore-tail -- commands to be executed
|
|
after the Netfilter configuration is restored.<br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, traffic from the firewall to a dynamic zone member host did
|
|
not need to match the interface specified when the host was added to the
|
|
zone. For example, if eth0:1.2.3.4 is added to dynamic zone Z then
|
|
traffic out of any firewall interface to 1.2.3.4 will obey the fw->Z
|
|
policies and rules. This has been corrected.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>Variable expansion may now be used with the INCLUDE directive.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/params<br>
|
|
<br>
|
|
|
|
FILE=/etc/foo/bar<br>
|
|
<br>
|
|
Any other config file:<br>
|
|
<br>
|
|
|
|
INCLUDE $FILE<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_2_0_Beta6"></a>11/26/2004 -
|
|
Shorewall 2.2.0 Beta 6<br>
|
|
<br>
|
|
</span> Beta 5 was more or less DOA. Here's Beta 6.<br>
|
|
<br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>Fixed a number of problems associated with not having an IPTABLES value
|
|
assigned in shorewall.conf</li>
|
|
<li>Corrected a 'duplicate chain' error on "shorewall add" when the 'mss'
|
|
option is present in /etc/shorewall/ipsec.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_2_0_Beta5"></a>11/26/2004 -
|
|
Shorewall 2.2.0 Beta 5<br>
|
|
</span> <br>
|
|
Problems corrected:<br>
|
|
|
|
<ol>
|
|
<li>A typo in shorewall.conf (NETNOTSYN) has been corrected.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>For consistency, the CLIENT PORT(S) column in the tcrules file has been
|
|
renamed SOURCE PORT(S).</li>
|
|
<li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now shown in
|
|
the output of "shorewall status".</li>
|
|
<li>A new IPTABLES option has been added to shorewall.conf. IPTABLES can be
|
|
used to designate the iptables executable to be used by Shorewall. If not
|
|
specified, the iptables executable determined by the PATH setting is
|
|
used.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_0_11"></a>11/23/2004 - Shorewall
|
|
2.0.11<br>
|
|
</span> <br>
|
|
Problems corrected:<br>
|
|
|
|
<ol>
|
|
<li>The INSTALL file now include special instructions for Slackware
|
|
users.</li>
|
|
<li>The bogons file has been updated.</li>
|
|
<li>Service names are replaced by port numbers in /etc/shorewall/tos.</li>
|
|
<li>A typo in the install.sh file that caused an error during a new install
|
|
has been corrected.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>The AllowNNTP action now allows NNTP over SSL/TLS (NTTPS).<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_2_0_Beta4"></a>11/19/2004 -
|
|
Shorewall 2.2.0 Beta 4<br>
|
|
</span> <br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>A cut and paste error resulted in some nonsense in the description of
|
|
the IPSEC column in /etc/shorewall/masq.</li>
|
|
<li>A typo in /etc/shorewall/rules has been corrected.</li>
|
|
<li>The bogons file has been updated.</li>
|
|
<li>The "shorewall add" command previously reported success but did nothing
|
|
-- now it works.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>The AllowNNTP action now allows NNTP over SSL/TLS (NNTPS).<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_2_0_Beta3"></a>11/09/2004 -
|
|
Shorewall 2.2.0 Beta 3<br>
|
|
</span> <br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>Missing '#' in the rfc1918 file has been corrected.</li>
|
|
<li>The INSTALL file now includes special instructions for Slackware
|
|
users.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>In CLASSIFY rules (/etc/shorewall/tcrules), an interface name may now
|
|
appear in the DEST column as in:<br>
|
|
|
|
<pre> #MARK/ SOURCE DEST PROTO PORT(S)<br>
|
|
#CLASSIFY<br>
|
|
1:30 - eth0 tcp 25</pre>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_2_0_Beta2"></a>11/02/2004 -
|
|
Shorewall 2.2.0 Beta 2<br>
|
|
<br>
|
|
</span> Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>The "shorewall check" command results in the (harmless) error
|
|
message:<br>
|
|
<br>
|
|
/usr/share/shorewall/firewall:
|
|
line 2753:<br>
|
|
|
|
check_dupliate_zones: command not found<br>
|
|
<br>
|
|
</li>
|
|
<li>The AllowNTP standard action now allows outgoing responses to
|
|
broadcasts.</li>
|
|
<li>A clarification has been added to the hosts file's description of the
|
|
'ipsec' option pointing out that the option is redundent if the zone
|
|
named in the ZONE column has been designated an IPSEC zone in the
|
|
/etc/shorewall/ipsec file.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>The SUBNET column in /etc/shorewall/rfc1918 has been renamed SUBNETS
|
|
and it is now possible to specify a list of addresses in that column.<br>
|
|
</li>
|
|
</ol>
|
|
<span style="font-weight: bold;"><a name="2_0_10"></a>10/25/2004 - Shorewall
|
|
2.0.10<br>
|
|
</span> <br>
|
|
Problems Corrected:<br>
|
|
|
|
<ol>
|
|
<li>The GATEWAY column was previously ignored in 'pptpserver' entries in
|
|
/etc/shorewall/tunnels.</li>
|
|
<li>When log rule numbers are included in the LOGFORMAT, duplicate rule
|
|
numbers could previously be generated.</li>
|
|
<li>The /etc/shorewall/tcrules file now includes a note to the effect that
|
|
rule evaluation continues after a match.</li>
|
|
<li>The error message produced if Shorewall couldn't obtain the routes
|
|
through an interface named in the SUBNET column of /etc/shorewall/masq
|
|
was less than helpful since it didn't include the interface name.<br>
|
|
</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>The "shorewall status" command has been enhanced to include the values
|
|
of key /proc settings:<br>
|
|
<br>
|
|
Example from a two-interface firewall:<br>
|
|
<br>
|
|
/proc<br>
|
|
<br>
|
|
/proc/sys/net/ipv4/ip_forward = 1<br>
|
|
/proc/sys/net/ipv4/conf/all/proxy_arp = 0<br>
|
|
/proc/sys/net/ipv4/conf/all/arp_filter = 0<br>
|
|
/proc/sys/net/ipv4/conf/all/rp_filter = 0<br>
|
|
/proc/sys/net/ipv4/conf/default/proxy_arp = 0<br>
|
|
/proc/sys/net/ipv4/conf/default/arp_filter = 0<br>
|
|
/proc/sys/net/ipv4/conf/default/rp_filter = 0<br>
|
|
/proc/sys/net/ipv4/conf/eth0/proxy_arp = 0<br>
|
|
/proc/sys/net/ipv4/conf/eth0/arp_filter = 0<br>
|
|
/proc/sys/net/ipv4/conf/eth0/rp_filter = 0<br>
|
|
/proc/sys/net/ipv4/conf/eth1/proxy_arp = 0<br>
|
|
/proc/sys/net/ipv4/conf/eth1/arp_filter = 0<br>
|
|
/proc/sys/net/ipv4/conf/eth1/rp_filter = 0<br>
|
|
/proc/sys/net/ipv4/conf/lo/proxy_arp = 0<br>
|
|
/proc/sys/net/ipv4/conf/lo/arp_filter = 0<br>
|
|
/proc/sys/net/ipv4/conf/lo/rp_filter = 0<br>
|
|
</li>
|
|
</ol>
|
|
<br>
|
|
<span style="font-weight: bold;"><a name="2_2_0_Beta1"></a>10/24/2004 -
|
|
Shorewall 2.2.0 Beta1<br>
|
|
<br>
|
|
</span> The first beta in the 2.2 series is now available. Download location
|
|
is:<br>
|
|
<br>
|
|
|
|
|
|
<div style="margin-left: 40px;">
|
|
<a
|
|
href="http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1">http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1</a><br>
|
|
<a target="_top"
|
|
href="ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1">ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1</a><br>
|
|
</div>
|
|
|
|
<p>The features available in this release and the migration considerations
|
|
are covered in the <a
|
|
href="http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1/releasenotes.txt">release
|
|
notes</a>. Highlights include:<br>
|
|
</p>
|
|
<ol>
|
|
<li>The behavior produced by specifying a log level in an action invocation
|
|
is now much more rational. Previously, all packets sent to the action
|
|
were logged; now each rule within the invoked action behaves as if
|
|
logging had been specified on it.</li>
|
|
<li>Support for the 2.6 Kernel's native IPSEC implementation is now
|
|
available.</li>
|
|
<li>Support for ipp2p is included.</li>
|
|
<li>Support for the iptables CONNMARK facility is now included in
|
|
Shorewall.</li>
|
|
<li>A new LOGALLNEW option facilitates problem analysis.</li>
|
|
<li>Users with a large static blacklist can now defer loading the blacklist
|
|
until after the rest of the ruleset has been enabled. Doing so can
|
|
decrease substantially the amount of time that connections are disabled
|
|
during <span style="font-weight: bold;">shorewall [re]start</span>.</li>
|
|
<li>Support for the iptables 'iprange match' feature has been enabled.
|
|
Users whose kernel and iptables contain this feature can use ip address
|
|
ranges in most places in their Shorewall configuration where a CIDR
|
|
netowrk can be used.</li>
|
|
<li>Accepting of source routing and martian logging may now be
|
|
enabled/disabled on each interface.</li>
|
|
<li>Shorewall now supports the CLASSIFY iptable target.</li>
|
|
</ol>
|
|
|
|
<p><span style="font-weight: bold;"><a name="2_0_9"></a>9/23/2004 - Shorewall
|
|
2.0.9<br>
|
|
</span><br>
|
|
Problems Corrected:<br>
|
|
</p>
|
|
<ol>
|
|
<li>Previously, an empty PROTO column or a value of "all" in that column
|
|
would cause errors when processing the /etc/shorewall/tcrules file.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>The "shorewall status" command now includes the output of "brctl show"
|
|
if the bridge tools are installed.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><a name="SupportChange"><b>9/20/2004 – Change in
|
|
Shorewall Support</b></a></p>
|
|
|
|
<p style="">Friends,</p>
|
|
|
|
<p style="">The demands that my job and my personal life are currently
|
|
placing on me are such that supporing Shorewall to the extent that I have
|
|
been doing is just not possible any more.</p>
|
|
|
|
<p style="">I will continue to be active on the development list and will
|
|
continue to develop Shorewall if at all possible.</p>
|
|
|
|
<p style="">I will also continue to read the user's list and will help with
|
|
problems that interest me. But I am no longer going to hop on every problem
|
|
as soon as I see it.</p>
|
|
|
|
<p style="">This change means that I'm going to have to depend on you folks
|
|
to help each other; I'm confident that we can make this work.</p>
|
|
|
|
<p><a name="2_0_8"></a><b>8/22/2004 - Shorewall 2.0.8<br>
|
|
</b><br>
|
|
Problems Corrected:</p>
|
|
<ol>
|
|
<li><p>Entries in the USER/GROUP column of an action file (made from
|
|
action.template) may be ignored or cause odd errors.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><a name="2_0_7"></a><b>7/29/2004 - Shorewall 2.0.7<br>
|
|
<br>
|
|
</b> Problems Corrected:</p>
|
|
<ol>
|
|
<li><p style="margin-bottom: 0in;">The PKTTYPE option introduced in version
|
|
2.0.6 is now used when generating rules to REJECT packets. Broadcast
|
|
packets are silently dropped rather than being rejected with an ICMP
|
|
(which is a protocol violation) and users whose kernels have broken
|
|
packet type match support are likely to see messages reporting this
|
|
violation. Setting PKTTYPE=No should cause these messages to cease.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">Multiple interfaces with the 'blacklist'
|
|
option no longer result in an error message at startup.</p>
|
|
</li>
|
|
<li><p>The following has been added to /etc/shorewall/bogons:<br>
|
|
<br>
|
|
0.0.0.0 RETURN<br>
|
|
<br>
|
|
This prevents the 'nobogons' option from logging DHCP 'DISCOVER'
|
|
broadcasts.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>New Features:</p>
|
|
<ol>
|
|
<li><p>To improve supportability, the "shorewall status" command now
|
|
includes IP and Route configuration information.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
<font face="monospace">IP Configuration</font><br>
|
|
<br>
|
|
<font face="monospace">1: lo: <LOOPBACK,UP> mtu 16436
|
|
qdisc noqueue</font><br>
|
|
<font face="monospace">link/loopback
|
|
00:00:00:00:00:00 brd 00:00:00:00:00:00</font><br>
|
|
<font face="monospace">inet 127.0.0.1/8
|
|
brd 127.255.255.255 scope host lo</font><br>
|
|
<font face="monospace">inet6 ::1/128 scope
|
|
host</font><br>
|
|
<font face="monospace">2: eth0:
|
|
<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen
|
|
1000</font><br>
|
|
<font face="monospace">link/ether
|
|
00:a0:c9:15:39:78 brd ff:ff:ff:ff:ff:ff</font><br>
|
|
<font face="monospace">inet6
|
|
fe80::2a0:c9ff:fe15:3978/64 scope link</font><br>
|
|
<font face="monospace">3: eth1:
|
|
<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen
|
|
1000</font><br>
|
|
<font face="monospace">link/ether
|
|
00:a0:c9:a7:d7:bf brd ff:ff:ff:ff:ff:ff</font><br>
|
|
<font face="monospace">inet6
|
|
fe80::2a0:c9ff:fea7:d7bf/64 scope link</font><br>
|
|
<font face="monospace">5: sit0@NONE: <NOARP> mtu 1480
|
|
qdisc noop</font><br>
|
|
<font face="monospace">link/sit 0.0.0.0
|
|
brd 0.0.0.0</font><br>
|
|
<font face="monospace">6: eth2:
|
|
<BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen
|
|
1000</font><br>
|
|
<font face="monospace">link/ether
|
|
00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff</font><br>
|
|
<font face="monospace">inet6
|
|
fe80::240:d0ff:fe07:3a1b/64 scope link</font><br>
|
|
<font face="monospace">7: br0:
|
|
<BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc
|
|
noqueue</font><br>
|
|
<font face="monospace">link/ether
|
|
00:40:d0:07:3a:1b brd ff:ff:ff:ff:ff:ff</font><br>
|
|
<font face="monospace">inet 192.168.1.3/24
|
|
brd 192.168.1.255 scope global br0</font><br>
|
|
<font face="monospace">inet6
|
|
fe80::240:d0ff:fe07:3a1b/64 scope link</font><br>
|
|
<br>
|
|
<font face="monospace">Routing Rules</font><br>
|
|
<br>
|
|
<font face="monospace">0: from
|
|
all lookup local</font><br>
|
|
<font face="monospace">32765: from all
|
|
fwmark ca lookup www.out</font><br>
|
|
<font face="monospace">32766: from all lookup
|
|
main</font><br>
|
|
<font face="monospace">32767: from all lookup
|
|
default</font><br>
|
|
<br>
|
|
<font face="monospace">Table local:</font><br>
|
|
<br>
|
|
<font face="monospace">broadcast 192.168.1.0 dev br0
|
|
proto kernel scope link src 192.168.1.3</font><br>
|
|
<font face="monospace">broadcast 127.255.255.255 dev
|
|
lo proto kernel scope link src 127.0.0.1</font><br>
|
|
<font face="monospace">local 192.168.1.3 dev br0 proto
|
|
kernel scope host src 192.168.1.3</font><br>
|
|
<font face="monospace">broadcast 192.168.1.255 dev br0
|
|
proto kernel scope link src 192.168.1.3</font><br>
|
|
<font face="monospace">broadcast 127.0.0.0 dev lo
|
|
proto kernel scope link src 127.0.0.1</font><br>
|
|
<font face="monospace">local 127.0.0.1 dev lo proto
|
|
kernel scope host src 127.0.0.1</font><br>
|
|
<font face="monospace">local 127.0.0.0/8 dev lo proto
|
|
kernel scope host src 127.0.0.1</font><br>
|
|
<br>
|
|
<font face="monospace">Table www.out:</font><br>
|
|
<br>
|
|
<font face="monospace">default via 192.168.1.3 dev
|
|
br0</font><br>
|
|
<br>
|
|
<font face="monospace">Table main:</font><br>
|
|
<br>
|
|
<font face="monospace">192.168.1.0/24 dev br0 proto
|
|
kernel scope link src 192.168.1.3</font><br>
|
|
<font face="monospace">default via 192.168.1.254 dev
|
|
br0</font><br>
|
|
<br>
|
|
<font face="monospace">Table default:</font></p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><a name="2_0_6"></a><b>7/16/2004 - Shorewall 2.0.6<br>
|
|
<br>
|
|
</b> Problems Corrected:</p>
|
|
<ul>
|
|
<li><p style="margin-bottom: 0in;">Some users have reported the packet type
|
|
match option in iptables/Netfilter failing to match certain broadcast
|
|
packets. The result is that the firewall log shows a lot of broadcast
|
|
packets.<br>
|
|
<br>
|
|
Other users have complained of the following message when starting
|
|
Shorewall:<br>
|
|
<br>
|
|
|
|
modprobe: cant locate module ipt_pkttype<br>
|
|
<br>
|
|
Users experiencing either of these problems can use PKTTYPE=No in
|
|
shorewall.conf to cause Shorewall to use IP address filtering of
|
|
broadcasts rather than packet type.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The shorewall.conf and zones file are no
|
|
longer given execute permission by the installer script.</p>
|
|
</li>
|
|
<li><p>ICMP packets that are in the INVALID state are now dropped by the
|
|
Reject and Drop default actions. They do so using the new 'dropInvalid'
|
|
builtin action.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p><a name="2_0_5"></a><b>7/10/2004 - Shorewall 2.0.5<br>
|
|
</b><br>
|
|
Problems Corrected:</p>
|
|
<ul>
|
|
<li><p style="margin-bottom: 0in;">If DISABLE_IPV6=Yes in shorewall.conf
|
|
then harmless error messages referring to $RESTOREBASE are generated
|
|
during <b>shorewall stop</b>.</p>
|
|
</li>
|
|
<li><p>An anachronistic comment concerning a mangle option has been removed
|
|
from shorewall.conf.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p><a name="2_0_4"></a><b>7/06/2004 - Shorewall 2.0.4<br>
|
|
</b><br>
|
|
Problems Corrected:</p>
|
|
<ul>
|
|
<li><p>Rules with $FW as the source zone and that specify logging can cause
|
|
"shorewall start" to fail.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p><a name="Release_Model"></a><b>7/03/2004 - New Shorewall Release Model<br>
|
|
<br>
|
|
</b> Effective today, Shorewall is adopting a new release model which takes
|
|
ideas from the one used in the Linux Kernel and from the release model for
|
|
Postfix.</p>
|
|
<ol>
|
|
<li><p style="margin-bottom: 0in;">Releases continue to have a three-level
|
|
identification <i>x.y.z</i> (e.g., 2.0.3).</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The first two levels (<i>x.y)</i>
|
|
designate the <i>Major Release Number</i> (e.g., 2.0)</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The third level (<i>z</i>) designates
|
|
the <i>Minor Release Number</i>.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">Even numbered major releases (e.g.,
|
|
<i>1.4, 2.0, 2.2, ...)</i> are <i>Stable Releases</i>. No new features
|
|
are added to stable releases and new minor releases of a stable release
|
|
will only contain bug fixes. Installing a new minor release for the major
|
|
release that you are currently running involves no migration issues (for
|
|
example, if you are running 1.4.10 and I release 1.4.11, your current
|
|
configuration is 100% compatible with the new release).</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">Support is available through the <a
|
|
href="http://lists.shorewall.net/">Mailing List</a> for the two most
|
|
recent Stable Releases.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">Odd numbered major releases (e.g., 2.1,
|
|
2.3, ...) are <i>Development Releases</i>. Development releases are where
|
|
new functionality is introduced. Documentation for new features will be
|
|
available but it may not be up to the standards of the stable release
|
|
documentation. Sites running Development Releases should be prepared to
|
|
play an active role in testing new features. Bug fixes and problem
|
|
resolution for the development release take a back seat to support of the
|
|
stable releases. Problem reports for the current development release
|
|
should be sent to the <a
|
|
href="mailto:shorewall-devel@lists.shorewall.net">Shorewall Development
|
|
Mailing List</a>.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">When the level of functionality of the
|
|
current development release is judged adaquate, the Beta period for a new
|
|
Stable release will begin. Beta releases have identifications of the form
|
|
<i>x.y.0-BetaN</i> where <i>x.y</i> is the number of the next Stable
|
|
Release and <i>N</i>=1,2,3... . Betas are expected to occur rougly once
|
|
per year. Beta releases may contain new functionality not present in the
|
|
previous beta release (e.g., 2.2.0-Beta4 may contain functionality not
|
|
present in 2.2.0-Beta3). When I'm confident that the current Beta release
|
|
is stable, I will release the first <i>Release Candidate.</i> Release
|
|
candidates have identifications of the form <i>x.y.0-RCn</i> where
|
|
<i>x.y</i> is the number of the next Stable Release and <i>n</i>=1,2,3...
|
|
. Release candidates contain no new functionailty -- they only contain
|
|
bug fixes. When the stability of the current release candidate is judged
|
|
to be sufficient then that release candidate will be released as the new
|
|
stable release (e.g., 2.2.0). At that time, the new stable release and
|
|
the prior stable release are those that are supported.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">What does it mean for a major release to
|
|
be <i>supported?</i> It means that I will answer questions about the
|
|
release and that if a bug is found, I will fix the bug and include the
|
|
fix in the next minor release.</p>
|
|
</li>
|
|
<li><p>Between minor releases, bug fixes will continue to be made available
|
|
through the Errata page for each major release.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>The immediate implications of this change are as follows:</p>
|
|
<ol>
|
|
<li><p style="margin-bottom: 0in;">The functionality of the 2.0 major
|
|
release is frozen at the level of minor release 2.0.3.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The two major releases currently
|
|
supported are 1.4 and 2.0.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">I will be opening the 2.1 development
|
|
release shortly with the release of 2.1.0.</p>
|
|
</li>
|
|
<li><p>Bug-fix releases with identifications of the form <i>x.y.zX</i>
|
|
where X=a,b,c,... (e.g., 2.0.3c) will not be seen in the future.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><a name="2_0_3c"></a><b>7/02/2004 - Shorewall 2.0.3c<br>
|
|
<br>
|
|
</b> Problems Corrected<b>:</b></p>
|
|
<ol>
|
|
<li><p style="margin-bottom: 0in;">Error messages regarding $RESTOREBASE
|
|
occur during <b>shorewall stop</b></p>
|
|
</li>
|
|
<li><p>If CLEAR_TC=Yes in <tt>shorewall.conf</tt>, <b>shorewall stop</b>
|
|
fails without removing the lock file.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><a name="2_0_3b"></a><b><br>
|
|
6/30/2004 - Shorewall 2.0.3b and Shorewall 1.4.10g<br>
|
|
<br>
|
|
</b> Problems Corrected:</p>
|
|
<ol>
|
|
<li><p style="margin-bottom: 0in;">The security vulnerability fix released
|
|
in Shorewall 2.0.3a failed under Slackware 9.1.</p>
|
|
</li>
|
|
<li><p>The security vulnerability fix released in Shorewall 2.0.3a failed
|
|
if mktemp was not installed.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><a name="2_0_3a"></a><b>6/28/2004 - Shorewall 2.0.3a and Shorewall
|
|
1.4.10f<br>
|
|
<br>
|
|
</b> Problems Corrected:</p>
|
|
<ol>
|
|
<li><p style="margin-bottom: 0in;">Javier Fernández-Sanguino
|
|
Peña has discovered an exploitable vulnerability in the
|
|
way that Shorewall handles temporary files and directories. The
|
|
vulnerability can allow a non-root user to cause arbitrary files on the
|
|
system to be overwritten. LEAF Bering and Bering uClibc users are
|
|
generally not at risk due to the fact that LEAF boxes do not typically
|
|
allow logins by non-root users.</p>
|
|
</li>
|
|
<li><p>(2.0.3a only) A non-empty DEST entry in /etc/shorewall/tcrules will
|
|
generate an error and Shorewall fails to start.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p style="margin-left: 0.42in;">Note:: Slackware users may need the
|
|
'functions' file from CVS (STABLE/ project for 1.4.10f and STABLE2/ project
|
|
for 2.0.3a) to prevent startup errors with these versions installed. These
|
|
updatged files are also available from the Errata (<a
|
|
href="errata.htm">2.0,</a> <a href="1.4/errata.htm">1.4</a>).</p>
|
|
|
|
<p><a name="2_0_3"></a><b>6/23/2004 - Shorewall 2.0.3<br>
|
|
<br>
|
|
</b> Problems Corrected:</p>
|
|
<ol>
|
|
<li><p style="margin-bottom: 0in;">The 'firewall' script is not purging
|
|
temporary restore files in /var/lib/shorewall. These files have names of
|
|
the form "restore-nnnnn".</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The /var/lib/shorewall/restore script
|
|
did not load the kernel modules specified in /etc/shorewall/modules.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">Specifying a null common action in
|
|
/etc/shorewall/actions (e.g., :REJECT) results in a startup error.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">If /var/lib/shorewall does not exist,
|
|
shorewall start fails.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">DNAT rules with a dynamic source zone
|
|
don't work properly. When used, these rules cause the rule to be checked
|
|
against ALL input, not just input from the designated zone.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The install.sh script reported
|
|
installing some files in /etc/shorewall when the files were actually
|
|
installed in /usr/share/shorewall.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">Shorewall checks netfilter capabilities
|
|
before loading kernel modules. Hence if kernel module autoloading isn't
|
|
enabled, the capabilities will be misdetected.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The 'newnotsyn' option in
|
|
/etc/shorewall/hosts has no effect.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The file /etc/init.d/shorewall now gets
|
|
proper ownership when the RPM is built by a non-root user.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">Rules that specify bridge ports in both
|
|
the SOURCE and DEST columns no longer cause "shorewall start" to fail.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">Comments in the rules file have been
|
|
added to advise users that "all" in the SOURCE or DEST column does not
|
|
affect intra-zone traffic.</p>
|
|
</li>
|
|
<li><p>With BLACKLISTNEWONLY=Yes, ICMP packets with state INVALID are now
|
|
passed through the blacklisting chains. Without this change, it is not
|
|
possible to blacklist hosts that are mounting certain types of ICMP-based
|
|
DOS attacks.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Issues when migrating from Shorewall 2.0.2 to Shorewall 2.0.3:</p>
|
|
<ol>
|
|
<li><p>The 'dropNonSyn' standard builtin action has been replaced with the
|
|
'dropNotSyn' standard builtin action. The old name can still be used but
|
|
will generate a warning.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>New Features:</p>
|
|
<ol>
|
|
<li><p style="margin-bottom: 0in;">Shorewall now supports multiple saved
|
|
configurations.</p>
|
|
<ol>
|
|
<li><p style="margin-bottom: 0in;">The default saved configuration
|
|
(restore script) in /var/lib/shorewall is now specified using the
|
|
RESTOREFILE option in shorewall.conf. If this variable isn't set then
|
|
to maintain backward compatibility, 'restore' is assumed.<br>
|
|
<br>
|
|
The value of RESTOREFILE must be a simple file name; no slashes ("/")
|
|
may be included.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The "save" command has been extended
|
|
to be able to specify the name of a saved configuration.<br>
|
|
<br>
|
|
|
|
shorewall save [ <file name> ]<br>
|
|
<br>
|
|
The current state is saved to /var/lib/shorewall/<file name>.
|
|
If no <file name> is given, the configuration is saved to the
|
|
file determined by the RESTOREFILE setting.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The "restore" command has been
|
|
extended to be able to specify the name of a saved configuration:<br>
|
|
<br>
|
|
shorewall
|
|
restore [ <file name> ]<br>
|
|
<br>
|
|
The firewall state is restored from /var/lib/shorewall/<file
|
|
name>. If no <file name> is given, the firewall state is
|
|
restored from the file determined by the RESTOREFILE setting.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The "forget" command has changed.
|
|
Previously, the command unconditionally removed the
|
|
/var/lib/shorewall/save file which records the current dynamic
|
|
blacklist. The "forget" command now leaves that file alone.<br>
|
|
<br>
|
|
Also, the "forget" command has been extended to be able to specify
|
|
the name of a saved configuration:<br>
|
|
<br>
|
|
|
|
shorewall forget [ <file name> ]<br>
|
|
<br>
|
|
The file /var/lib/shorewall/<file name> is removed. If no
|
|
<file name> is given, the file determined by the RESTOREFILE
|
|
setting is removed.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">The "shorewall -f start" command
|
|
restores the state from the file determined by the RESTOREFILE
|
|
setting.</p>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">"!" is now allowed in accounting
|
|
rules.</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">Interface names appearing within the
|
|
configuration are now verified. Interface names must match the name of an
|
|
entry in /etc/shorewall/interfaces (or if bridging is enabled, they must
|
|
match the name of an entry in /etc/shorewall/interfaces or the name of a
|
|
bridge port appearing in /etc/shorewall/hosts).</p>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">A new 'rejNotSyn' built-in standard
|
|
action has been added. This action responds to "New not SYN" packets with
|
|
an RST.<br>
|
|
<br>
|
|
The 'dropNonSyn' action has been superceded by the new 'dropNotSyn'
|
|
action. The old name will be accepted until the next major release of
|
|
Shorewall but will generate a warning.<br>
|
|
<br>
|
|
Several new logging actions involving "New not SYN" packets have been
|
|
added:<br>
|
|
<br>
|
|
logNewNotSyn -- logs the
|
|
packet with disposition = LOG<br>
|
|
dLogNewNotSyn -- logs the
|
|
packet with disposition = DROP<br>
|
|
rLogNewNotSyn -- logs the
|
|
packet with disposition = REJECT<br>
|
|
<br>
|
|
The packets are logged at the log level specified in the LOGNEWNOTSYN
|
|
option in shorewall.conf. If than option is empty or not specified, then
|
|
'info' is assumed.<br>
|
|
<br>
|
|
Examples (In all cases, set NEWNOTSYN=Yes in shorewall.conf):</p>
|
|
<ol>
|
|
<li><p style="margin-bottom: 0in;">To simulate the behavior of
|
|
NEWNOTSYN=No:</p>
|
|
<ol>
|
|
<li><p style="margin-bottom: 0in;">Add 'NoNewNotSyn' to
|
|
/etc/shorewall/actions.</p>
|
|
</li>
|
|
<li><p>Create /etc/shorewall/action.NoNewNotSyn containing:<br>
|
|
<br>
|
|
|
|
dLogNotSyn<br>
|
|
|
|
dropNotSyn</p>
|
|
</li>
|
|
<li><p>Early in your rules file, place:<br>
|
|
<br>
|
|
|
|
NoNewNotSyn all
|
|
all tcp</p>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li><p style="margin-bottom: 0in;">Drop 'New not SYN' packets from the
|
|
net only. Don't log them:</p>
|
|
<ol>
|
|
<li><p>Early in your rules file, place:<br>
|
|
<br>
|
|
|
|
dropNotSyn
|
|
net all
|
|
tcp</p>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li><p>Slackware users no longer have to modify the install.sh script
|
|
before installation. Tuomo Soini has provided a change that allows the
|
|
INIT and FIREWALL variables to be specified outside the script as in:<br>
|
|
<br>
|
|
DEST=/etc/rc.d INIT=rc.firewall
|
|
./install.sh</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>6/3/2004 - Shorewall 2.0.2f<br>
|
|
</b></p>
|
|
|
|
<p>Fixes one problem:<br>
|
|
</p>
|
|
<ol>
|
|
<li>Versions 2.0.2d and 2.0.2e fail to load kernel modules unless
|
|
MODULE_SUFFIX is set in shorewall.conf<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>6/2/2004 - Shorewall 2.0.2e<br>
|
|
</b></p>
|
|
|
|
<p>One problem corrected:<br>
|
|
</p>
|
|
<ol>
|
|
<li>LOG rules within an action generate two Netfilter logging rules.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>5/28/2004 - Shorewall 2.0.2d<br>
|
|
</b><br>
|
|
One problem corrected:<br>
|
|
</p>
|
|
<ol>
|
|
<li>Shorewall was checking capabilities before loading kernel modules.
|
|
Consequently, if kernel module autoloading was disabled, the capabilities
|
|
were mis-detected.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>5/21/2004 - Shorewall 2.0.2c</b></p>
|
|
One problem corrected:<br>
|
|
|
|
<ol>
|
|
<li> DNAT rules with a dynamic source zone don't work properly. When
|
|
used, these rules cause the rule to be checked against ALL input,
|
|
not just input from the designated zone.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>5/18/2004 - Shorewall 2.0.2b</b><b> </b></p>
|
|
|
|
<p>Corrects two problems:</p>
|
|
<ol>
|
|
<li>Specifying a null common action in /etc/shorewall/actions (e.g.,
|
|
:REJECT) results in a startup error.<br>
|
|
<br>
|
|
</li>
|
|
<li>If /var/lib/shorewall does not exist, shorewall start fails.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>5/15/2004 - Shorewall 2.0.2a</b><br>
|
|
</p>
|
|
|
|
<p>Corrects two problems:<br>
|
|
</p>
|
|
<ol>
|
|
<li>Temporary restore files were not being removed from /var/lib/shorewall.
|
|
These files have names of the form 'restore-nnnnn'. You can remove
|
|
files that have accumulated with the command:<br>
|
|
<br>
|
|
rm -f /var/lib/shorewall/restore-[0-9]*<br>
|
|
<br>
|
|
</li>
|
|
<li>The restore script did not load kernel modules. The result was that
|
|
after a cold load, applications like FTP and IRC DCC didn't work.<br>
|
|
<br>
|
|
To correct:<br>
|
|
<br>
|
|
1) Install 2.0.2a<br>
|
|
2) "shorewall restart"<br>
|
|
3) "shorewall save"</li>
|
|
</ol>
|
|
|
|
<p><b>5/13/2004 - Shorewall 2.0.2</b><b> </b></p>
|
|
|
|
<p>Problems Corrected since 2.0.1<br>
|
|
</p>
|
|
<ol>
|
|
<li>The /etc/init.d/shorewall script installed on Debian by install.sh
|
|
failed silently due to a missing file (/usr/share/shorewall/wait4ifup).
|
|
That file is not part of the normal Shorewall distribution and is
|
|
provided by the Debian maintainer.</li>
|
|
<li>A meaningless warning message out of the proxyarp file processing has
|
|
been eliminated.</li>
|
|
<li>The "shorewall delete" command now correctly removes all dynamic rules
|
|
pertaining to the host(s) being deleted. Thanks to Stefan Engel for this
|
|
correction.</li>
|
|
</ol>
|
|
Issues when migrating from Shorewall 2.0.1 to Shorewall 2.0.2:<br>
|
|
|
|
<ol>
|
|
<li>Extension Scripts -- In order for extension scripts to work properly
|
|
with the new iptables-save/restore integration (see New Feature 1 below),
|
|
some change may be required to your extension scripts. If your extension
|
|
scripts are executing commands other than iptables then those commands
|
|
must also be written to the restore file (a temporary file in
|
|
/var/lib/shorewall that is renamed /var/lib/shorewall/restore-base at the
|
|
end of the operation).<br>
|
|
<br>
|
|
The following functions should be of help:<br>
|
|
<br>
|
|
A. save_command() -- saves the passed command to the restore file.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
save_command echo Operation
|
|
Complete<br>
|
|
<br>
|
|
That command would simply write "echo Operation Complete" to
|
|
the restore file.<br>
|
|
<br>
|
|
B. run_and_save_command() -- saves the passed command to the restore file
|
|
then executes it. The return value is the exit status of the command.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
run_and_save_command "echo 1 >
|
|
/proc/sys/net/ipv4/icmp_echo_ignore_all"<br>
|
|
<br>
|
|
Note that as in this example, when the command
|
|
involves file redirection then the entire command must be enclosed in
|
|
quotes. This applies to all of the functions described here.<br>
|
|
<br>
|
|
C. ensure_and_save_command() -- runs the passed command. If the command
|
|
fails, the firewall is restored to it's prior saved state and the
|
|
operation is terminated. If the command succeeds, the command is written
|
|
to the restore file.<br>
|
|
<br>
|
|
</li>
|
|
<li>Dynamic Zone support -- If you don't need to use the "shorewall add"
|
|
and "shorewall delete commands, you should set DYNAMIC_ZONES=No in
|
|
/etc/shorewall/shorewall.conf.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>Shorewall has now been integrated with iptables-save/iptables-restore
|
|
to provide very fast start and restart. The elements of this integration
|
|
are as follows:<br>
|
|
<br>
|
|
a) The 'shorewall save' command now saves the current configuration in
|
|
addition to the current dynamic blacklist. If you have dynamic zones, you
|
|
will want to issue 'shorewall save' when the zones are empty or the
|
|
current contents of the zones will be restored by the 'shorewall restore'
|
|
and 'shorewall -f start' commands.<br>
|
|
<br>
|
|
b) The 'shorewall restore' command has been added. This command restores
|
|
the configuration at the time of the last 'save'.<br>
|
|
<br>
|
|
c) The -f (fast) option has been added to 'shorewall start'. When
|
|
specified (e.g. 'shorewall -f start'), shorewall will perform a
|
|
'shorewall restore' if there is a saved configuration. If there is no
|
|
saved configuration, a normal 'shorewall start' is performed.<br>
|
|
<br>
|
|
d) The /etc/init.d/shorewall script now translates the 'start' command
|
|
into 'shorewall -f start' so that fast restart is possible.<br>
|
|
<br>
|
|
e) When a state-changing command encounters an error and there is current
|
|
saved configuration, that configuration will be restored (currently, the
|
|
firewall is placed in the 'stopped' state).<br>
|
|
<br>
|
|
f) If you have previously saved the running configuration and want
|
|
Shorewall to discard it, use the 'shorewall forget' command. WARNING:
|
|
iptables 1.2.9 is broken with respect to iptables-save; if your kernel
|
|
has connection tracking match support, you must patch iptables 1.2.9 with
|
|
the iptables patch availale from the Shorewall errata page.<br>
|
|
<br>
|
|
</li>
|
|
<li>The previous implementation of dynamic zones was difficult to maintain.
|
|
I have changed the code to make dynamic zones optional under the control
|
|
of the DYNAMIC_ZONES option in /etc/shorewall/shorewall.conf.<br>
|
|
<br>
|
|
</li>
|
|
<li>In earlier Shorewall 2.0 releases, Shorewall searches in order the
|
|
following directories for configuration files.<br>
|
|
<br>
|
|
a) The directory specified in a 'try' command or specified using the -c
|
|
option.<br>
|
|
b) /etc/shorewall<br>
|
|
c) /usr/share/shorewall<br>
|
|
<br>
|
|
In this release, the CONFIG_PATH option is added to shorewall.conf.
|
|
CONFIG_PATH contains a list of directory names separated by colons (":").
|
|
If not set or set to a null value (e.g., CONFIG_PATH="") then
|
|
"CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed. Now
|
|
Shorewall searches for shorewall.conf according to the old rules and for
|
|
other configuration files as follows:<br>
|
|
<br>
|
|
a) The directory specified in a 'try' command or specified using the -c
|
|
option.<br>
|
|
b) Each directory in $CONFIG_PATH is searched in sequence.<br>
|
|
<br>
|
|
In case it is not obvious, your CONFIG_PATH should include
|
|
/usr/share/shorewall and your shorewall.conf file must be in the
|
|
directory specified via -c or in a try command, in /etc/shorewall or in
|
|
/usr/share/shorewall.<br>
|
|
<br>
|
|
For distribution packagers, the default CONFIG_PATH is set in
|
|
/usr/share/shorewall/configpath. You can customize this file to have a
|
|
default that differs from mine.<br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, in /etc/shorewall/nat a Yes (or yes) in the LOCAL column
|
|
would only take effect if the ALL INTERFACES column also contained Yes or
|
|
yes. Now, the LOCAL columns contents are treated independently of the
|
|
contents of the ALL INTERFACES column.<br>
|
|
<br>
|
|
</li>
|
|
<li>The folks at Mandrake have created yet another kernel module naming
|
|
convention (module names end in "ko.gz"). As a consequence, beginning
|
|
with this release, if MODULE_SUFFIX isn't specified in shorewall.conf,
|
|
then the default value is "o gz ko o.gz ko.gz".<br>
|
|
<br>
|
|
</li>
|
|
<li>An updated bogons file is included in this release.<br>
|
|
<br>
|
|
</li>
|
|
<li>In /etc/shorewall/rules and in action files generated from
|
|
/usr/share/shorewall/action.template, rules that perform logging can
|
|
specify an optional "log tag". A log tag is a string of alphanumeric
|
|
characters and is specified by following the log level with ":" and the
|
|
log tag.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
ACCEPT:info:ftp
|
|
net dmz
|
|
tcp 21<br>
|
|
<br>
|
|
The log tag is appended to the log prefix generated by the LOGPREFIX
|
|
variable in /etc/shorewall/conf. If "ACCEPT:info" generates the log
|
|
prefix "Shorewall:net2dmz:ACCEPT:" then "ACCEPT:info:ftp" will generate
|
|
"Shorewall:net2dmz:ACCEPT:ftp " (note the trailing blank). The maximum
|
|
length of a log prefix supported by iptables is 29 characters; if a
|
|
larger prefix is generated, Shorewall will issue a warning message and
|
|
will truncate the prefix to 29 characters.<br>
|
|
<br>
|
|
</li>
|
|
<li>A new "-q" option has been added to /sbin/shorewall commands. It causes
|
|
the start, restart, check and refresh commands to produce much less
|
|
output so that warning messages are more visible (when testing this
|
|
change, I discovered a bug where a bogus warning message was being
|
|
generated).<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall now uses 'modprobe' to load kernel modules if that utility is
|
|
available in the PATH; otherwise, 'insmod' is used.<br>
|
|
<br>
|
|
</li>
|
|
<li>It is now possible to restrict entries in the /etc/shorewall/masq file
|
|
to particular protocols and destination port(s). Two new columns (PROTO
|
|
and PORT(S)) have been added to the file.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
You want all outgoing SMTP traffic entering the firewall on eth1 to be
|
|
sent from eth0 with source IP address 206.124.146.177. You want all other
|
|
outgoing traffic from eth1 to be sent from eth0 with source IP address
|
|
206.124.146.176.<br>
|
|
<br>
|
|
eth0
|
|
eth1 206.124.146.177 tcp 25<br>
|
|
eth0
|
|
eth1 206.124.146.176<br>
|
|
<br>
|
|
THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!<br>
|
|
<br>
|
|
Assuming that 10.0.0.0/8 is the only host/network connected to eth1, the
|
|
progress message at "shorewall start" would be:<br>
|
|
<br>
|
|
Masqueraded Networks and Hosts:<br>
|
|
To 0.0.0.0/0 (tcp 25) from
|
|
10.0.0.0/8 through eth0 using 206.124.146.177<br>
|
|
To 0.0.0.0/0 (all) from 10.0.0.0/8
|
|
through eth0 using 206.124.146.176<br>
|
|
<br>
|
|
</li>
|
|
<li>Two new actions are available in the /etc/shorewall/rules file.<br>
|
|
<br>
|
|
ACCEPT+ -- Behaves like ACCEPT with
|
|
the exception that it exempts matching connections from subsequent
|
|
DNAT[-] and REDIRECT[-] rules.<br>
|
|
NONAT -- Exempts
|
|
matching connections from subsequent DNAT[-] and REDIRECT[-] rules.<br>
|
|
<br>
|
|
</li>
|
|
<li>A new extension script 'initdone' has been added. This script is
|
|
invoked at the same point as the 'common' script was previously and is
|
|
useful for users who mis-used that script under Shorewall 1.x (the script
|
|
was intended for adding rules to the 'common' chain but many users
|
|
treated it as a script for adding rules before Shorewall's).<br>
|
|
<br>
|
|
</li>
|
|
<li>Installing/Upgrading Shorewall on Slackware has been improved.
|
|
Slackware users must use the tarball and must modify settings in the
|
|
install.sh script before running it as follows:<br>
|
|
<br>
|
|
DEST="/etc/rc.d"<br>
|
|
INIT="rc.firewall"<br>
|
|
<br>
|
|
Thanks to Alex Wilms for helping with this change.</li>
|
|
</ol>
|
|
|
|
<p><b>4/17/2004 - Presentation at LinuxFest NW</b><b><br>
|
|
</b></p>
|
|
Today I gave a presentation at LinuxFest NW in Bellingham. The presentation
|
|
was entitled "<a
|
|
href="http://lists.shorewall.net/Shorewall_and_the_Enterprise.htm"
|
|
target="_blank">Shorewall and the Enterprise</a>" and described the history
|
|
of Shorewall and gave an overview of its features.
|
|
|
|
<p><b>4/5/2004 - Shorewall 2.0.1</b><br>
|
|
</p>
|
|
Problems Corrected since 2.0.0<br>
|
|
<br>
|
|
|
|
<ol>
|
|
<li>Using actions in the manner recommended in the documentation results in
|
|
a Warning that the rule is a policy.</li>
|
|
<li>When a zone on a single interface is defined using
|
|
/etc/shorewall/hosts, superfluous rules are generated in the
|
|
<zone>_frwd chain.</li>
|
|
<li>Thanks to Sean Mathews, a long-standing problem with Proxy ARP and
|
|
IPSEC has been corrected. Thanks Sean!!!</li>
|
|
<li>The "shorewall show log" and "shorewall logwatch" commands incorrectly
|
|
displayed type 3 ICMP packets.<br>
|
|
</li>
|
|
</ol>
|
|
Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:<br>
|
|
<br>
|
|
|
|
<ol>
|
|
<li>The function of 'norfc1918' is now split between that option and a new
|
|
'nobogons' option.<br>
|
|
<br>
|
|
The rfc1918 file released with Shorewall now contains entries for only
|
|
those three address ranges reserved by RFC 1918. A 'nobogons' interface
|
|
option has been added which handles bogon source addresses (those which
|
|
are reserved by the IANA, those reserved for DHCP auto-configuration and
|
|
the class C test-net reserved for testing and documentation examples).
|
|
This will allow users to perform RFC 1918 filtering without having to
|
|
deal with out of date data from IANA. Those who are willing to update
|
|
their /usr/share/shorewall/bogons file regularly can specify the
|
|
'nobogons' option in addition to 'norfc1918'.<br>
|
|
<br>
|
|
The level at which bogon packets are logged is specified in the new
|
|
BOGON_LOG_LEVEL variable in shorewall.conf. If that option is not
|
|
specified or is specified as empty (e.g, BOGON_LOG_LEVEL="") then bogon
|
|
packets whose TARGET is 'logdrop' in /usr/share/shorewall/bogons are
|
|
logged at the 'info' level.</li>
|
|
</ol>
|
|
New Features:<br>
|
|
<br>
|
|
|
|
<ol>
|
|
<li>Support for Bridging Firewalls has been added. For details, see<br>
|
|
<br>
|
|
<a
|
|
href="http://shorewall.net/bridge.html">http://shorewall.net/bridge.html</a><br>
|
|
<br>
|
|
</li>
|
|
<li>Support for NETMAP has been added. NETMAP allows NAT to be defined
|
|
between two network:<br>
|
|
<br>
|
|
|
|
a.b.c.1 -> x.y.z.1<br>
|
|
|
|
a.b.c.2 -> x.y.z.2<br>
|
|
|
|
a.b.c.3 -> x.y.z.3<br>
|
|
...<br>
|
|
<br>
|
|
<a
|
|
href="http://shorewall.net/netmap.htm">http://shorewall.net/netmap.htm</a><br>
|
|
<br>
|
|
</li>
|
|
<li>The /sbin/shorewall program now accepts a "-x" option to cause iptables
|
|
to print out the actual packet and byte counts rather than abbreviated
|
|
counts such as "13MB".<br>
|
|
<br>
|
|
Commands affected by this are:<br>
|
|
<br>
|
|
|
|
shorewall -x show [ <chain>[ <chain> ...] ]<br>
|
|
|
|
shorewall -x show tos|mangle<br>
|
|
|
|
shorewall -x show nat<br>
|
|
|
|
shorewall -x status<br>
|
|
|
|
shorewall -x monitor [ <interval> ]<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall now traps two common zone definition errors:<br>
|
|
|
|
<ul>
|
|
<li>Including the firewall zone in a /etc/shorewall/hosts record.</li>
|
|
<li>Defining an interface for a zone in both /etc/shorewall/interfaces
|
|
and /etc/shorewall/hosts.<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>In the second case, the following will appear during "shorewall
|
|
[re]start" or "shorewall check":<br>
|
|
<br>
|
|
Determining Hosts in Zones...<br>
|
|
...<br>
|
|
Error: Invalid zone definition for zone
|
|
<name of zone><br>
|
|
Terminated<br>
|
|
<br>
|
|
</li>
|
|
<li>To support bridging, the following options have been added to entries
|
|
in /etc/shorewall/hosts:<br>
|
|
<br>
|
|
norfc1918<br>
|
|
nobogons<br>
|
|
blacklist<br>
|
|
tcpflags<br>
|
|
nosmurfs<br>
|
|
newnotsyn<br>
|
|
<br>
|
|
With the exception of 'newnotsyn', these options are only useful when the
|
|
entry refers to a bridge port.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
#ZONE HOST(S)
|
|
OPTIONS<br>
|
|
net br0:eth0
|
|
norfc1918,nobogons,blacklist,tcpflags,nosmurfs</li>
|
|
</ol>
|
|
|
|
<p><b>3/14/2004 - Shorewall 2.0.0b </b></p>
|
|
Corrects two problems:<br>
|
|
|
|
<ol>
|
|
<li>Thanks to Sean Mathews, the long-standing problem with Proxy ARP and
|
|
IPSEC has been eliminated!</li>
|
|
<li>The default value of the ALL INTERFACES column in /etc/shorewall/nat is
|
|
documented as 'No' but the default continued to be 'Yes' as it was in
|
|
Shorewall 1.4.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>3/14/2004 - Shorewall 2.0.0a </b></p>
|
|
|
|
<p>Corrects one problem:<br>
|
|
</p>
|
|
<ul>
|
|
<li>Rules of the form:<br>
|
|
<br>
|
|
<action>
|
|
zone1 zone2<br>
|
|
<br>
|
|
generated a warning stating that the rule was a policy.<br>
|
|
</li>
|
|
</ul>
|
|
|
|
<p><b>3/14/2004 - Shorewall 2.0.0</b> <b><br>
|
|
</b></p>
|
|
|
|
<p>Dedicated to Agnes Van Slyke Eastep: March 14, 1910 - February 23, 2004<br>
|
|
</p>
|
|
|
|
<p>Problems Corrected since 1.4.10<br>
|
|
</p>
|
|
<ol>
|
|
<li>A blank USER/GROUP column in /etc/shorewall/tcrules no longer causes a
|
|
[re]start error.</li>
|
|
<li>The 'fgrep' utility is no longer required (caused startup problems on
|
|
LEAF/Bering).</li>
|
|
<li>The "shorewall add" command no longer inserts rules before checking of
|
|
the blacklist.</li>
|
|
<li>The 'detectnets' and 'routeback' options may now be used together with
|
|
the intended effect.</li>
|
|
<li>The following syntax previously produced an error:<br>
|
|
<br>
|
|
DNAT z1!z2,z3 z4...<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Problems Corrected since RC2<br>
|
|
<br>
|
|
</p>
|
|
<ol>
|
|
<li>CONTINUE rules now work again.</li>
|
|
<li>A comment in the rules file has been corrected.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Issues when migrating from Shorewall 1.4.x to Shorewall 2.0.0:<br>
|
|
</p>
|
|
<ol>
|
|
<li>The 'dropunclean' and 'logunclean' interface options are no longer
|
|
supported. If either option is specified in /etc/shorewall/interfaces, an
|
|
threatening message will be generated.</li>
|
|
<li>The NAT_BEFORE_RULES option has been removed from shorewall.conf. The
|
|
behavior of Shorewall is as if NAT_BEFORE_RULES=No had been specified. In
|
|
other words, DNAT rules now always take precidence over one-to-one NAT
|
|
specifications.</li>
|
|
<li>The default value for the ALL INTERFACES column in /etc/shorewall/nat
|
|
has changed. In Shorewall 1.*, if the column was left empty, a value of
|
|
"Yes" was assumed. This has been changed so that a value of "No" is now
|
|
assumed.</li>
|
|
<li>The following files don't exist in Shorewall 2.0:<br>
|
|
/etc/shorewall/common.def<br>
|
|
/etc/shorewall/common<br>
|
|
/etc/shorewall/icmpdef<br>
|
|
/etc/shorewall/action.template (Moved to /usr/share/shorewall)<br>
|
|
/etc/shorewall/rfc1918 (Moved to /usr/share/shorewall).<br>
|
|
<br>
|
|
The /etc/shorewall/action file now allows an action to be designated as
|
|
the "common" action for a particular policy type by following the action
|
|
name with ":" and the policy (DROP, REJECT or ACCEPT).<br>
|
|
<br>
|
|
The file /usr/share/shorewall/actions.std has been added to define those
|
|
actions that are released as part of Shorewall. In that file are two
|
|
actions as follows:<br>
|
|
<br>
|
|
Drop:DROP<br>
|
|
Reject:REJECT<br>
|
|
<br>
|
|
The "Drop" action is the common action for DROP policies while the
|
|
"Reject" action is the default action for "REJECT" policies. These
|
|
actions will be performed on packets prior to applying the DROP or REJECT
|
|
policy respectively. In the first release, the difference between
|
|
"Reject" and "Drop" is that "Reject" REJECTs SMB traffic while "Drop"
|
|
silently drops such traffic.<br>
|
|
<br>
|
|
As described above, Shorewall allows a common action for ACCEPT policies
|
|
but does not specify such an action in the default configuration.<br>
|
|
<br>
|
|
If for some reason, you don't wish to have a common DROP or REJECT
|
|
action, just include :DROP or :REJECT respectively in your
|
|
/etc/shorewall/actions file.<br>
|
|
<br>
|
|
The file /usr/share/shorewall/actions.std catalogs the standard actions
|
|
and is processed prior to /etc/shorewall/actions. This causes a large
|
|
number of actions to be defined. The files which define these aactions
|
|
are also located in /usr/share/shorewall as is the he action template
|
|
file (action.template).<br>
|
|
<br>
|
|
These actions may be used in the ACTION column of the rules column. So
|
|
for example, to allow FTP from your loc zone to your firewall, you would
|
|
place this rule in /etc/shorewall/rules:<br>
|
|
<br>
|
|
#ACTION
|
|
SOURCE DEST<br>
|
|
AllowFTP
|
|
loc
|
|
fw<br>
|
|
<br>
|
|
If you want to redefine any of the Shorewall-defined actions, simply copy
|
|
the appropriate action file from /usr/share/shorewall to /etc/shorewall
|
|
and modify the copy as desired. Your modified copy will be used rather
|
|
than the original one in /usr/share/shorewall.<br>
|
|
<br>
|
|
Note: The 'dropBcast' and 'dropNonSyn' actions are built into Shorewall
|
|
and may not be changed.<br>
|
|
<br>
|
|
Beginning with version 2.0.0-Beta2, Shorewall will only create a chain
|
|
for those actions that are actually used.<br>
|
|
<br>
|
|
</li>
|
|
<li>The /etc/shorewall directory no longer contains a 'users' file or a
|
|
'usersets' file. Similar functionality is now available using
|
|
user-defined actions.<br>
|
|
<br>
|
|
Now, action files created by copying /usr/share/shorewall/action.template
|
|
may specify a USER and or GROUP name/id in the final column just like in
|
|
the rules file (see below). It is thus possible to create actions that
|
|
control traffic from a list of users and/or groups.<br>
|
|
<br>
|
|
The last column in /etc/shorewall/rules is now labeled USER/GROUP and may
|
|
contain:<br>
|
|
<br>
|
|
[!]<user number>[:]<br>
|
|
[!]<user name>[:]<br>
|
|
[!]:<group number><br>
|
|
[!]:<group name><br>
|
|
[!]<user number>:<group number><br>
|
|
[!]<user number>:<group name><br>
|
|
[!]<user name>:<group number><br>
|
|
[!]<user name>:<group name><br>
|
|
<br>
|
|
</li>
|
|
<li>It is no longer possible to specify rate limiting in the ACTION column
|
|
of /etc/shorewall/rules -- you must use the RATE LIMIT column.<br>
|
|
<br>
|
|
</li>
|
|
<li>Depending on which method you use to upgrade, if you have your own
|
|
version of /etc/shorewall/rfc1918, you may have to take special action to
|
|
restore it after the upgrade. Look for /etc/shorewall/rfc1918*, locate
|
|
the proper file and rename it back to /etc/shorewall/rfc1918. The
|
|
contents of that file will supercede the contents of
|
|
/usr/share/shorewall/rfc1918.</li>
|
|
</ol>
|
|
|
|
<p>New Features:<br>
|
|
</p>
|
|
<ol>
|
|
<li>The INCLUDE directive now allows absolute file names.</li>
|
|
<li>A 'nosmurfs' interface option has been added to
|
|
/etc/shorewall/interfaces. When specified for an interface, this option
|
|
causes smurfs (packets with a broadcast address as their source) to be
|
|
dropped and optionally logged (based on the setting of a new
|
|
SMURF_LOG_LEVEL option in shorewall.conf).</li>
|
|
<li>fw->fw traffic may now be controlled by Shorewall. There is no need
|
|
to define the loopback interface in /etc/shorewall/interfaces; you simply
|
|
add a fw->fw policy and fw->fw rules. If you have neither a
|
|
fw->fw policy nor fw->fw rules, all fw->fw traffic is
|
|
allowed.</li>
|
|
<li>There is a new PERSISTENT column in the proxyarp file. A value of "Yes"
|
|
in this column means that the route added by Shorewall for this host will
|
|
remain after a "shorewall stop" or "shorewall clear".</li>
|
|
<li>"trace" is now a synonym for "debug" in /sbin/shorewall commands. So to
|
|
trace the "start" command, you could enter:<br>
|
|
<br>
|
|
shorewall trace start 2> /tmp/trace<br>
|
|
<br>
|
|
The trace information would be written to the file /tmp/trace.<br>
|
|
<br>
|
|
</li>
|
|
<li>When defining an ipsec tunnel in /etc/shorewall/tunnels, if you follow
|
|
the tunnel type ("ipsec" or "ipsecnet") with ":noah" (e.g.,
|
|
"ipsec:noah"), then Shorewall will only create rules for ESP (protocol
|
|
50) and will not create rules for AH (protocol 51).</li>
|
|
<li>A new DISABLE_IPV6 option has been added to shorewall.conf. When this
|
|
option is set to "Yes", Shorewall will set the policy for the IPv6 INPUT,
|
|
OUTPUT and FORWARD chains to DROP during "shorewall [re]start" and
|
|
"shorewall stop". Regardless of the setting of this variable, "shorewall
|
|
clear" will silently attempt to set these policies to ACCEPT.<br>
|
|
<br>
|
|
If this option is not set in your existing shorewall.conf then a setting
|
|
of DISABLE_IPV6=No is assumed in which case, Shorewall will not touch any
|
|
IPv6 settings except during "shorewall clear".</li>
|
|
<li>The CONTINUE target is now available in action definitions. CONTINUE
|
|
terminates processing of the current action and returns to the point
|
|
where that action was invoked.</li>
|
|
</ol>
|
|
|
|
<p><b>2/15/2004 - Shorewall 1.4.10c </b></p>
|
|
|
|
<p>Corrects one problem:<br>
|
|
</p>
|
|
Entries in /etc/shorewall/tcrules with an empty USER/GROUP column would cause
|
|
a startup error.
|
|
|
|
<p><b>2/12/2004 - Shorewall 1.4.10b </b></p>
|
|
|
|
<p>Corrects one problem:<br>
|
|
</p>
|
|
<ul>
|
|
<li>In the /etc/shorewall/masq entry “<span
|
|
class="quote">eth0:!10.1.1.150 0.0.0.0/0!10.1.0.0/16
|
|
10.1.2.16</span>”, the “<span
|
|
class="quote">!10.1.0.0/16</span>” is ignored.</li>
|
|
</ul>
|
|
|
|
<p><b>2/8/2004 - Shorewall 1.4.10a </b></p>
|
|
|
|
<p>Corrects two problems:<br>
|
|
</p>
|
|
<ul>
|
|
<li>A problem which can cause [re]start to fail inexplicably while
|
|
processing /etc/shorewall/masq.</li>
|
|
<li>Interfaces using the Atheros WiFi card to use the 'maclist' option.</li>
|
|
</ul>
|
|
|
|
<p><b>1/30/2004 - Shorewall 1.4.10</b></p>
|
|
|
|
<p>Problems Corrected since version 1.4.9</p>
|
|
<ol>
|
|
<li>The column descriptions in the action.template file did not match the
|
|
column headings. That has been corrected.</li>
|
|
<li>The presence of IPV6 addresses on devices generated error messages
|
|
during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
|
|
specified in /etc/shorewall/shorewall.conf. These messages have been
|
|
eliminated.</li>
|
|
<li value="3">The CONTINUE action in /etc/shorewall/rules now works
|
|
correctly. A couple of problems involving rate limiting have been
|
|
corrected. These bug fixes courtesy of Steven Jan Springl.</li>
|
|
<li>Shorewall now tried to avoid sending an ICMP response to broadcasts and
|
|
smurfs.</li>
|
|
<li>Specifying "-" or "all" in the PROTO column of an action no longer
|
|
causes a startup error.</li>
|
|
</ol>
|
|
Migragion Issues:<br>
|
|
<br>
|
|
None.<br>
|
|
<br>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>The INTERFACE column in the /etc/shorewall/masq file may now specify a
|
|
destination list.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
#INTERFACE
|
|
SUBNET ADDRESS<br>
|
|
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
|
<br>
|
|
If the list begins with "!" then SNAT will occur only if the destination
|
|
IP address is NOT included in the list.<br>
|
|
<br>
|
|
</li>
|
|
<li>Output traffic control rules (those with the firewall as the source)
|
|
may now be qualified by the effective userid and/or effective group id of
|
|
the program generating the output. This feature is courtesy of
|
|
Frédéric LESPEZ.<br>
|
|
<br>
|
|
A new USER column has been added to /etc/shorewall/tcrules. It may
|
|
contain :<br>
|
|
<br>
|
|
[<user name or number>]:[<group
|
|
name or number>]<br>
|
|
<br>
|
|
The colon is optionnal when specifying only a user.<br>
|
|
<br>
|
|
Examples : john: / john / :users /
|
|
john:users<br>
|
|
<br>
|
|
</li>
|
|
<li>A "detectnets" interface option has been added for entries in
|
|
/etc/shorewall/interfaces. This option automatically tailors the
|
|
definition of the zone named in the ZONE column to include just
|
|
those hosts that have routes through the interface named in the INTERFACE
|
|
column. The named interface must be UP when Shorewall is [re]started.<br>
|
|
<br>
|
|
WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>1/27/2004 - Shorewall 1.4.10 RC3</b></p>
|
|
|
|
<p><a
|
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
</p>
|
|
|
|
<p>Problems Corrected since version 1.4.9</p>
|
|
<ol>
|
|
<li>The column descriptions in the action.template file did not match the
|
|
column headings. That has been corrected.</li>
|
|
<li>The presence of IPV6 addresses on devices generated error messages
|
|
during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
|
|
specified in /etc/shorewall/shorewall.conf. These messages have been
|
|
eliminated.</li>
|
|
<li value="3">The CONTINUE action in /etc/shorewall/rules now works
|
|
correctly. A couple of problems involving rate limiting have been
|
|
corrected. These bug fixes courtesy of Steven Jan Springl.</li>
|
|
<li>Shorewall now tried to avoid sending an ICMP response to broadcasts and
|
|
smurfs.<br>
|
|
</li>
|
|
</ol>
|
|
Migragion Issues:<br>
|
|
<br>
|
|
None.<br>
|
|
<br>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>The INTERFACE column in the /etc/shorewall/masq file may now specify a
|
|
destination list.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
#INTERFACE
|
|
SUBNET ADDRESS<br>
|
|
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
|
<br>
|
|
If the list begins with "!" then SNAT will occur only if the destination
|
|
IP address is NOT included in the list.<br>
|
|
<br>
|
|
</li>
|
|
<li>Output traffic control rules (those with the firewall as the source)
|
|
may now be qualified by the effective userid and/or effective group id of
|
|
the program generating the output. This feature is courtesy of
|
|
Frédéric LESPEZ.<br>
|
|
<br>
|
|
A new USER column has been added to /etc/shorewall/tcrules. It may
|
|
contain :<br>
|
|
<br>
|
|
[<user name or number>]:[<group
|
|
name or number>]<br>
|
|
<br>
|
|
The colon is optionnal when specifying only a user.<br>
|
|
<br>
|
|
Examples : john: / john / :users /
|
|
john:users<br>
|
|
<br>
|
|
</li>
|
|
<li>A "detectnets" interface option has been added for entries in
|
|
/etc/shorewall/interfaces. This option automatically tailors the
|
|
definition of the zone named in the ZONE column to include just
|
|
those hosts that have routes through the interface named in the INTERFACE
|
|
column. The named interface must be UP when Shorewall is [re]started.<br>
|
|
<br>
|
|
WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>1/24/2004 - Shorewall 1.4.10 RC2</b><b> </b></p>
|
|
|
|
<p><a
|
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
</p>
|
|
|
|
<p>Problems Corrected since version 1.4.9</p>
|
|
<ol>
|
|
<li>The column descriptions in the action.template file did not match the
|
|
column headings. That has been corrected.</li>
|
|
<li>The presence of IPV6 addresses on devices generated error messages
|
|
during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
|
|
specified in /etc/shorewall/shorewall.conf. These messages have been
|
|
eliminated.</li>
|
|
</ol>
|
|
Migragion Issues:<br>
|
|
<br>
|
|
None.<br>
|
|
<br>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>The INTERFACE column in the /etc/shorewall/masq file may now specify a
|
|
destination list.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
#INTERFACE
|
|
SUBNET ADDRESS<br>
|
|
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
|
<br>
|
|
If the list begins with "!" then SNAT will occur only if the destination
|
|
IP address is NOT included in the list.<br>
|
|
<br>
|
|
</li>
|
|
<li>Output traffic control rules (those with the firewall as the source)
|
|
may now be qualified by the effective userid and/or effective group id of
|
|
the program generating the output. This feature is courtesy of
|
|
Frédéric LESPEZ.<br>
|
|
<br>
|
|
A new USER column has been added to /etc/shorewall/tcrules. It may
|
|
contain :<br>
|
|
<br>
|
|
[<user name or number>]:[<group
|
|
name or number>]<br>
|
|
<br>
|
|
The colon is optionnal when specifying only a user.<br>
|
|
<br>
|
|
Examples : john: / john / :users /
|
|
john:users<br>
|
|
<br>
|
|
</li>
|
|
<li>A "detectnets" interface option has been added for entries in
|
|
/etc/shorewall/interfaces. This option automatically tailors the
|
|
definition of the zone named in the ZONE column to include just
|
|
those hosts that have routes through the interface named in the INTERFACE
|
|
column. The named interface must be UP when Shorewall is [re]started.<br>
|
|
<br>
|
|
WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!</li>
|
|
</ol>
|
|
|
|
<p><b>1/22/2004 - Shorewall 1.4.10 RC1</b><b> </b></p>
|
|
|
|
<p>Problems Corrected since version 1.4.9</p>
|
|
<ol>
|
|
<li>The column descriptions in the action.template file did not match the
|
|
column headings. That has been corrected.</li>
|
|
<li>The presence of IPV6 addresses on devices generated error messages
|
|
during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes are
|
|
specified in /etc/shorewall/shorewall.conf. These messages have been
|
|
eliminated.</li>
|
|
</ol>
|
|
Migragion Issues:<br>
|
|
<br>
|
|
None.<br>
|
|
<br>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>The INTERFACE column in the /etc/shorewall/masq file may now specify a
|
|
destination list.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
#INTERFACE
|
|
SUBNET ADDRESS<br>
|
|
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
|
<br>
|
|
If the list begins with "!" then SNAT will occur only if the destination
|
|
IP address is NOT included in the list.<br>
|
|
<br>
|
|
</li>
|
|
<li>Output traffic control rules (those with the firewall as the source)
|
|
may now be qualified by the effective userid and/or effective group id of
|
|
the program generating the output. This feature is courtesy of
|
|
Frédéric LESPEZ.<br>
|
|
<br>
|
|
A new USER column has been added to /etc/shorewall/tcrules. It may
|
|
contain :<br>
|
|
<br>
|
|
[<user name or number>]:[<group
|
|
name or number>]<br>
|
|
<br>
|
|
The colon is optionnal when specifying only a user.<br>
|
|
<br>
|
|
Examples : john: / john / :users /
|
|
john:users <br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>1/13/2004 - Shorewall 1.4.9</b><b><br>
|
|
</b></p>
|
|
|
|
<p>Problems Corrected since version 1.4.8:<br>
|
|
</p>
|
|
<ol>
|
|
<li>There has been a low continuing level of confusion over the terms
|
|
"Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all
|
|
instances of "Static NAT" have been replaced with "One-to-one NAT" in the
|
|
documentation and configuration files.</li>
|
|
<li>The description of NEWNOTSYN in shorewall.conf has been reworded for
|
|
clarity.</li>
|
|
<li>Wild-card rules (those involving "all" as SOURCE or DEST) will no
|
|
longer produce an error if they attempt to add a rule that would override
|
|
a NONE policy. The logic for expanding these wild-card rules now simply
|
|
skips those (SOURCE,DEST) pairs that have a NONE policy.</li>
|
|
<li>DNAT rules that also specified SNAT now work reliably. Previously,
|
|
there were cases where the SNAT specification was effectively
|
|
ignored.</li>
|
|
</ol>
|
|
|
|
<p>Migration Issues:<br>
|
|
<br>
|
|
None.<br>
|
|
<br>
|
|
New Features:<br>
|
|
</p>
|
|
<ol>
|
|
<li>The documentation has been completely rebased to Docbook XML. The
|
|
documentation is now released as separate HTML and XML packages.</li>
|
|
<li>To cut down on the number of "Why are these ports closed rather than
|
|
stealthed?" questions, the SMB-related rules in /etc/shorewall/common.def
|
|
have been changed from 'reject' to 'DROP'.</li>
|
|
<li>For easier identification, packets logged under the 'norfc1918'
|
|
interface option are now logged out of chains named 'rfc1918'.
|
|
Previously, such packets were logged under chains named 'logdrop'.</li>
|
|
<li>Distributors and developers seem to be regularly inventing new naming
|
|
conventions for kernel modules. To avoid the need to change Shorewall
|
|
code for each new convention, the MODULE_SUFFIX option has been added to
|
|
shorewall.conf. MODULE_SUFFIX may be set to the suffix for module names
|
|
in your particular distribution. If MODULE_SUFFIX is not set in
|
|
shorewall.conf, Shorewall will use the list "o gz ko o.gz".<br>
|
|
<br>
|
|
To see what suffix is used by your distribution:<br>
|
|
<br>
|
|
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
|
<br>
|
|
All of the files listed should have the same suffix (extension). Set
|
|
MODULE_SUFFIX to that suffix.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
If all files end in ".kzo" then set
|
|
MODULE_SUFFIX="kzo"<br>
|
|
If all files end in ".kz.o" then set
|
|
MODULE_SUFFIX="kz.o"</li>
|
|
<li>Support for user defined rule ACTIONS has been implemented through two
|
|
new files:<br>
|
|
<br>
|
|
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
|
/etc/shorewall/action.template - For each user defined <action>,
|
|
copy this file to /etc/shorewall/action.<action> and add the
|
|
appropriate rules for that <action>. Once an <action> has
|
|
been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
|
|
DROP, etc.) in /etc/shorewall/rules.<br>
|
|
<br>
|
|
Example: You want an action that logs a packet at the 'info' level and
|
|
accepts the connection.<br>
|
|
<br>
|
|
In /etc/shorewall/actions, you would add:<br>
|
|
<br>
|
|
LogAndAccept<br>
|
|
<br>
|
|
You would then copy /etc/shorewall/action.template to
|
|
/etc/shorewall/action.LogAndAccept and in that file, you would add the
|
|
two rules:<br>
|
|
LOG:info<br>
|
|
ACCEPT</li>
|
|
<li>The default value for NEWNOTSYN in shorewall.conf is now "Yes" (non-syn
|
|
TCP packets that are not part of an existing connection are filtered
|
|
according to the rules and policies rather than being dropped). I have
|
|
made this change for two reasons:<br>
|
|
<br>
|
|
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since any
|
|
timeout during TCP session tear down results in the firewall dropping all
|
|
of the retries.<br>
|
|
<br>
|
|
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots
|
|
of confusing messages when a connection got "stuck". While I could have
|
|
changed the default value of LOGNEWNOTSYN to suppress logging, I dislike
|
|
defaults that silently throw away packets.</li>
|
|
<li>The common.def file now contains an entry that silently drops ICMP
|
|
packets with a null source address. Ad Koster reported a case where these
|
|
were occuring frequently as a result of a broken system on his external
|
|
network.</li>
|
|
</ol>
|
|
|
|
<p><b>12/29/2003 - Shorewall 1.4.9 Beta 2</b></p>
|
|
|
|
<div style="margin-left: 40px;">
|
|
<a
|
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a> </div>
|
|
|
|
<p>Problems Corrected since version 1.4.8:</p>
|
|
<ol>
|
|
<li>There has been a low continuing level of confusion over the terms
|
|
"Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all
|
|
instances of "Static NAT" have been replaced with "One-to-one NAT" in the
|
|
documentation and configuration files.</li>
|
|
<li>The description of NEWNOTSYN in shorewall.conf has been reworded for
|
|
clarity.</li>
|
|
<li>Wild-card rules (those involving "all" as SOURCE or DEST) will no
|
|
longer produce an error if they attempt to add a rule that would override
|
|
a NONE policy. The logic for expanding these wild-card rules now simply
|
|
skips those (SOURCE,DEST) pairs that have a NONE policy.</li>
|
|
<li>DNAT rules that also specified SNAT now work reliably. Previously,
|
|
there were cases where the SNAT specification was effectively ignored.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Migration Issues:</p>
|
|
|
|
<p> None.<br>
|
|
<br>
|
|
New Features:</p>
|
|
<ol>
|
|
<li>The documentation has been completely rebased to Docbook XML. The
|
|
documentation is now released as separate HTML and XML packages.<br>
|
|
</li>
|
|
<li>To cut down on the number of "Why are these ports closed rather than
|
|
stealthed?" questions, the SMB-related rules in /etc/shorewall/common.def
|
|
have been changed from 'reject' to 'DROP'.</li>
|
|
<li>For easier identification, packets logged under the 'norfc1918'
|
|
interface option are now logged out of chains named 'rfc1918'.
|
|
Previously, such packets were logged under chains named 'logdrop'.</li>
|
|
<li>Distributors and developers seem to be regularly inventing new naming
|
|
conventions for kernel modules. To avoid the need to change Shorewall
|
|
code for each new convention, the MODULE_SUFFIX option has been added to
|
|
shorewall.conf. MODULE_SUFFIX may be set to the suffix for module names
|
|
in your particular distribution. If MODULE_SUFFIX is not set in
|
|
shorewall.conf, Shorewall will use the list "o gz ko o.gz".<br>
|
|
<br>
|
|
To see what suffix is used by your distribution:<br>
|
|
<br>
|
|
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
|
<br>
|
|
All of the files listed should have the same suffix (extension). Set
|
|
MODULE_SUFFIX to that suffix.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
If all files end in ".kzo" then set
|
|
MODULE_SUFFIX="kzo"<br>
|
|
If all files end in ".kz.o" then set
|
|
MODULE_SUFFIX="kz.o"</li>
|
|
<li>Support for user defined rule ACTIONS has been implemented through two
|
|
new files:<br>
|
|
<br>
|
|
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
|
/etc/shorewall/action.template - For each user defined <action>,
|
|
copy this file to /etc/shorewall/action.<action> and add the
|
|
appropriate rules for that <action>. Once an <action> has
|
|
been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
|
|
DROP, etc.) in /etc/shorewall/rules.<br>
|
|
<br>
|
|
Example: You want an action that logs a packet at the 'info' level and
|
|
accepts the connection.<br>
|
|
<br>
|
|
In /etc/shorewall/actions, you would add:<br>
|
|
<br>
|
|
LogAndAccept<br>
|
|
<br>
|
|
You would then copy /etc/shorewall/action.template to
|
|
/etc/shorewall/action.LogAndAccept and in that file, you would add the
|
|
two rules:<br>
|
|
LOG:info<br>
|
|
ACCEPT<br>
|
|
</li>
|
|
<li>The default value for NEWNOTSYN in shorewall.conf is now "Yes" (non-syn
|
|
TCP packets that are not part of an existing connection are filtered
|
|
according to the rules and policies rather than being dropped). I have
|
|
made this change for two reasons:<br>
|
|
<br>
|
|
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since any
|
|
timeout during TCP session tear down results in the firewall dropping all
|
|
of the retries.<br>
|
|
<br>
|
|
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots
|
|
of confusing messages when a connection got "stuck". While I could have
|
|
changed the default value of LOGNEWNOTSYN to suppress logging, I dislike
|
|
defaults that silently throw away packets.<br>
|
|
<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>12/28/2003 - www.shorewall.net/ftp.shorewall.net Back On-line</b>
|
|
<b><br>
|
|
</b></p>
|
|
|
|
<p>Our high-capacity server has been restored to service -- please let <a
|
|
href="mailto:webmaster@shorewall.net">us</a> know if you find any
|
|
problems.</p>
|
|
|
|
<p><b>12/29/2003 - Shorewall 1.4.9 Beta 1</b></p>
|
|
|
|
<div style="margin-left: 40px;">
|
|
<a
|
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a> </div>
|
|
|
|
<p>Problems Corrected since version 1.4.8:</p>
|
|
<ol>
|
|
<li>There has been a low continuing level of confusion over the terms
|
|
"Source NAT" (SNAT) and "Static NAT". To avoid future confusion, all
|
|
instances of "Static NAT" have been replaced with "One-to-one NAT" in the
|
|
documentation and configuration files.</li>
|
|
<li>The description of NEWNOTSYN in shorewall.conf has been reworded for
|
|
clarity.</li>
|
|
<li>Wild-card rules (those involving "all" as SOURCE or DEST) will no
|
|
longer produce an error if they attempt to add a rule that would override
|
|
a NONE policy. The logic for expanding these wild-card rules now simply
|
|
skips those (SOURCE,DEST) pairs that have a NONE policy.</li>
|
|
</ol>
|
|
|
|
<p>Migration Issues:</p>
|
|
|
|
<p> None.<br>
|
|
<br>
|
|
New Features:</p>
|
|
<ol>
|
|
<li>To cut down on the number of "Why are these ports closed rather than
|
|
stealthed?" questions, the SMB-related rules in /etc/shorewall/common.def
|
|
have been changed from 'reject' to 'DROP'.</li>
|
|
<li>For easier identification, packets logged under the 'norfc1918'
|
|
interface option are now logged out of chains named 'rfc1918'.
|
|
Previously, such packets were logged under chains named 'logdrop'.</li>
|
|
<li>Distributors and developers seem to be regularly inventing new naming
|
|
conventions for kernel modules. To avoid the need to change Shorewall
|
|
code for each new convention, the MODULE_SUFFIX option has been added to
|
|
shorewall.conf. MODULE_SUFFIX may be set to the suffix for module names
|
|
in your particular distribution. If MODULE_SUFFIX is not set in
|
|
shorewall.conf, Shorewall will use the list "o gz ko o.gz".<br>
|
|
<br>
|
|
To see what suffix is used by your distribution:<br>
|
|
<br>
|
|
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
|
<br>
|
|
All of the files listed should have the same suffix (extension). Set
|
|
MODULE_SUFFIX to that suffix.<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
If all files end in ".kzo" then set
|
|
MODULE_SUFFIX="kzo"<br>
|
|
If all files end in ".kz.o" then set
|
|
MODULE_SUFFIX="kz.o"</li>
|
|
<li>Support for user defined rule ACTIONS has been implemented through two
|
|
new files:<br>
|
|
<br>
|
|
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
|
/etc/shorewall/action.template - For each user defined <action>,
|
|
copy this file to /etc/shorewall/action.<action> and add the
|
|
appropriate rules for that <action>. Once an <action> has
|
|
been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
|
|
DROP, etc.) in /etc/shorewall/rules.<br>
|
|
<br>
|
|
Example: You want an action that logs a packet at the 'info' level and
|
|
accepts the connection.<br>
|
|
<br>
|
|
In /etc/shorewall/actions, you would add:<br>
|
|
<br>
|
|
LogAndAccept<br>
|
|
<br>
|
|
You would then copy /etc/shorewall/action.template to
|
|
/etc/shorewall/action.LogAndAccept and in that file, you would add the
|
|
two rules:<br>
|
|
LOG:info<br>
|
|
ACCEPT<br>
|
|
</li>
|
|
<li>The default value for NEWNOTSYN in shorewall.conf is now "Yes" (non-syn
|
|
TCP packets that are not part of an existing connection are filtered
|
|
according to the rules and policies rather than being dropped). I have
|
|
made this change for two reasons:<br>
|
|
<br>
|
|
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since any
|
|
timeout during TCP session tear down results in the firewall dropping all
|
|
of the retries.<br>
|
|
<br>
|
|
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in lots
|
|
of confusing messages when a connection got "stuck". While I could have
|
|
changed the default value of LOGNEWNOTSYN to suppress logging, I dislike
|
|
defaults that silently throw away packets.</li>
|
|
</ol>
|
|
|
|
<p><b>12/03/2003 - Support Torch Passed</b></p>
|
|
Effective today, I am reducing my participation in the day-to-day support of
|
|
Shorewall. As part of this shift to community-based Shorewall support a new
|
|
<a
|
|
href="https://lists.shorewall.net/mailman/listinfo/shorewall-newbies">Shorewall
|
|
Newbies mailing list</a> has been established to field questions and problems
|
|
from new users. I will not monitor that list personally. I will continue my
|
|
active development of Shorewall and will be available via the development
|
|
list to handle development issues -- Tom.
|
|
|
|
<p><b>11/07/2003 - Shorewall 1.4.8<br>
|
|
<br>
|
|
</b> Problems Corrected since version 1.4.7:<br>
|
|
</p>
|
|
<ol>
|
|
<li>Tuomo Soini has supplied a correction to a problem that occurs using
|
|
some versions of 'ash'. The symptom is that "shorewall start" fails
|
|
with:<br>
|
|
<br>
|
|
local: --limit: bad variable name<br>
|
|
iptables v1.2.8: Couldn't load match
|
|
`-j':/lib/iptables/libipt_-j.so:<br>
|
|
cannot open shared object file: No such file or directory<br>
|
|
Try `iptables -h' or 'iptables --help' for more
|
|
information.</li>
|
|
<li>Andres Zhoglo has supplied a correction that avoids trying to use the
|
|
multiport match iptables facility on ICMP rules.<br>
|
|
<br>
|
|
Example of rule that previously caused "shorewall start" to
|
|
fail:<br>
|
|
<br>
|
|
|
|
ACCEPT loc $FW
|
|
icmp 0,8,11,12<br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, if the following error message was issued, Shorewall was
|
|
left in an inconsistent state.<br>
|
|
<br>
|
|
Error: Unable to determine the routes through interface
|
|
xxx<br>
|
|
<br>
|
|
</li>
|
|
<li>Handling of the LOGUNCLEAN option in shorewall.conf has been
|
|
corrected.</li>
|
|
<li>In Shorewall 1.4.2, an optimization was added. This optimization
|
|
involved creating a chain named "<zone>_frwd" for most zones
|
|
defined using the /etc/shorewall/hosts file. It has since been discovered
|
|
that in many cases these new chains contain redundant rules and that the
|
|
"optimization" turns out to be less than optimal. The implementation has
|
|
now been corrected.</li>
|
|
<li>When the MARK value in a tcrules entry is followed by ":F" or ":P", the
|
|
":F" or ":P" was previously only applied to the first Netfilter rule
|
|
generated by the entry. It is now applied to all entries.</li>
|
|
<li>An incorrect comment concerning Debian's use of the SUBSYSLOCK option
|
|
has been removed from shorewall.conf.</li>
|
|
<li>Previously, neither the 'routefilter' interface option nor the
|
|
ROUTE_FILTER parameter were working properly. This has been corrected
|
|
(thanks to Eric Bowles for his analysis and patch). The definition of the
|
|
ROUTE_FILTER option has changed however. Previously, ROUTE_FILTER=Yes was
|
|
documented as enabling route filtering on all interfaces (which didn't
|
|
work). Beginning with this release, setting ROUTE_FILTER=Yes will enable
|
|
route filtering of all interfaces brought up while Shorewall is started.
|
|
As a consequence, ROUTE_FILTER=Yes can coexist with the use of the
|
|
'routefilter' option in the interfaces file.</li>
|
|
<li>If MAC verification was enabled on an interface with a /32 address and
|
|
a broadcast address then an error would occur during startup.</li>
|
|
<li>The NONE policy's intended use is to suppress the generating of rules
|
|
that can't possibly be traversed. This means that a policy of NONE is
|
|
inappropriate where the source or destination zone is $FW or "all".
|
|
Shorewall now generates an error message if such a policy is given in
|
|
/etc/shorewall/policy. Previously such a policy caused "shorewall start"
|
|
to fail.</li>
|
|
<li>The 'routeback' option was broken for wildcard interfaces (e.g.,
|
|
"tun+"). This has been corrected so that 'routeback' now works as
|
|
expected in this case.<br>
|
|
</li>
|
|
</ol>
|
|
Migration Issues:<br>
|
|
|
|
<ol>
|
|
<li>The definition of the ROUTE_FILTER option in shorewall.conf has changed
|
|
as described in item 8) above.<br>
|
|
</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>A new QUEUE action has been introduced for rules. QUEUE allows you to
|
|
pass connection requests to a user-space filter such as ftwall
|
|
(http://p2pwall.sourceforge.net). The ftwall program allows for effective
|
|
filtering of p2p applications such as Kazaa. For example, to use ftwall
|
|
to filter P2P clients in the 'loc' zone, you would add the following
|
|
rules:<br>
|
|
<br>
|
|
QUEUE loc
|
|
net tcp<br>
|
|
QUEUE loc
|
|
net udp<br>
|
|
QUEUE loc
|
|
fw udp<br>
|
|
<br>
|
|
You would normally want to place those three rules BEFORE any ACCEPT
|
|
rules for loc->net udp or tcp.<br>
|
|
<br>
|
|
Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), Shorewall
|
|
will only pass connection requests (SYN packets) to user space. This is
|
|
for compatibility with ftwall.</li>
|
|
<li>A BLACKLISTNEWNONLY option has been added to shorewall.conf. When this
|
|
option is set to "Yes", the blacklists (dynamic and static) are only
|
|
consulted for new connection requests. When set to "No" (the default if
|
|
the variable is not set), the blacklists are consulted on every
|
|
packet.<br>
|
|
<br>
|
|
Setting this option to "No" allows blacklisting to stop existing
|
|
connections from a newly blacklisted host but is more expensive in terms
|
|
of packet processing time. This is especially true if the blacklists
|
|
contain a large number of entries.</li>
|
|
<li>Chain names used in the /etc/shorewall/accounting file may now begin
|
|
with a digit ([0-9]) and may contain embedded dashes ("-").</li>
|
|
</ol>
|
|
|
|
<p><b>10/30/2003 - Shorewall 1.4.8 RC1<br>
|
|
</b></p>
|
|
Given the small number of new features and the relatively few lines of code
|
|
that were changed, there will be no Beta for 1.4.8.<br>
|
|
|
|
|
|
<p><b><a
|
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<br>
|
|
</b> Problems Corrected since version 1.4.7:<br>
|
|
</p>
|
|
<ol>
|
|
<li>Tuomo Soini has supplied a correction to a problem that occurs using
|
|
some versions of 'ash'. The symptom is that "shorewall start" fails
|
|
with:<br>
|
|
<br>
|
|
local: --limit: bad variable name<br>
|
|
iptables v1.2.8: Couldn't load match
|
|
`-j':/lib/iptables/libipt_-j.so:<br>
|
|
cannot open shared object file: No such file or directory<br>
|
|
Try `iptables -h' or 'iptables --help' for more
|
|
information.</li>
|
|
<li>Andres Zhoglo has supplied a correction that avoids trying to use the
|
|
multiport match iptables facility on ICMP rules.<br>
|
|
<br>
|
|
Example of rule that previously caused "shorewall start" to
|
|
fail:<br>
|
|
<br>
|
|
|
|
ACCEPT loc $FW
|
|
icmp 0,8,11,12<br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, if the following error message was issued, Shorewall was
|
|
left in an inconsistent state.<br>
|
|
<br>
|
|
Error: Unable to determine the routes through interface
|
|
xxx<br>
|
|
<br>
|
|
</li>
|
|
<li>Handling of the LOGUNCLEAN option in shorewall.conf has been
|
|
corrected.</li>
|
|
<li>In Shorewall 1.4.2, an optimization was added. This optimization
|
|
involved creating a chain named "<zone>_frwd" for most zones
|
|
defined using the /etc/shorewall/hosts file. It has since been discovered
|
|
that in many cases these new chains contain redundant rules and that the
|
|
"optimization" turns out to be less than optimal. The implementation has
|
|
now been corrected.</li>
|
|
<li>When the MARK value in a tcrules entry is followed by ":F" or ":P", the
|
|
":F" or ":P" was previously only applied to the first Netfilter rule
|
|
generated by the entry. It is now applied to all entries.</li>
|
|
<li>An incorrect comment concerning Debian's use of the SYBSYSLOCK option
|
|
has been removed from shorewall.conf.</li>
|
|
<li>Previously, neither the 'routefilter' interface option nor the
|
|
ROUTE_FILTER parameter were working properly. This has been corrected
|
|
(thanks to Eric Bowles for his analysis and patch). The definition of the
|
|
ROUTE_FILTER option has changed however. Previously, ROUTE_FILTER=Yes was
|
|
documented as enabling route filtering on all interfaces (which didn't
|
|
work). Beginning with this release, setting ROUTE_FILTER=Yes will enable
|
|
route filtering of all interfaces brought up while Shorewall is started.
|
|
As a consequence, ROUTE_FILTER=Yes can coexist with the use of the
|
|
'routefilter' option in the interfaces file.</li>
|
|
</ol>
|
|
Migration Issues:<br>
|
|
|
|
<ol>
|
|
<li>The definition of the ROUTE_FILTER option in shorewall.conf has changed
|
|
as described in item 8) above.<br>
|
|
</li>
|
|
</ol>
|
|
New Features:<br>
|
|
|
|
<ol>
|
|
<li>A new QUEUE action has been introduced for rules. QUEUE allows you to
|
|
pass connection requests to a user-space filter such as ftwall
|
|
(http://p2pwall.sourceforge.net). The ftwall program allows for effective
|
|
filtering of p2p applications such as Kazaa. For example, to use ftwall
|
|
to filter P2P clients in the 'loc' zone, you would add the following
|
|
rules:<br>
|
|
<br>
|
|
QUEUE loc
|
|
net tcp<br>
|
|
QUEUE loc
|
|
net udp<br>
|
|
QUEUE loc
|
|
fw udp<br>
|
|
<br>
|
|
You would normally want to place those three rules BEFORE any ACCEPT
|
|
rules for loc->net udp or tcp.<br>
|
|
<br>
|
|
Note: When the protocol specified is TCP ("tcp", "TCP" or "6"), Shorewall
|
|
will only pass connection requests (SYN packets) to user space. This is
|
|
for compatibility with ftwall.</li>
|
|
<li>A BLACKLISTNEWNONLY option has been added to shorewall.conf. When this
|
|
option is set to "Yes", the blacklists (dynamic and static) are only
|
|
consulted for new connection requests. When set to "No" (the default if
|
|
the variable is not set), the blacklists are consulted on every
|
|
packet.<br>
|
|
<br>
|
|
Setting this option to "No" allows blacklisting to stop existing
|
|
connections from a newly blacklisted host but is more expensive in terms
|
|
of packet processing time. This is especially true if the blacklists
|
|
contain a large number of entries.</li>
|
|
<li>Chain names used in the /etc/shorewall/accounting file may now begin
|
|
with a digit ([0-9]) and may contain embedded dashes ("-").<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper bag awards</b>
|
|
<b><img style="border: 0px solid ; width: 50px; height: 80px;"
|
|
src="images/j0233056.gif" title="" alt="" align="middle" />Shorewall 1.4.7c
|
|
released.</b></p>
|
|
<ol>
|
|
<li>The saga with "<zone>_frwd" chains continues. The 1.4.7c script
|
|
produces a ruleset that should work for everyone even if it is not quite
|
|
optimal. My apologies for this ongoing mess.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>10/24/2003 - Shorewall 1.4.7b</b></p>
|
|
This is a bugfx rollup of the 1.4.7a fixes plus:<br>
|
|
|
|
<ol>
|
|
<li>The fix for problem 5 in 1.4.7a was wrong with the result that
|
|
"<zone>_frwd" chains might contain too few rules. That wrong code
|
|
is corrected in this release.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>10/21/2003 - Shorewall 1.4.7a<br>
|
|
</b></p>
|
|
|
|
<p>This is a bugfix rollup of the following problem corrections:<br>
|
|
</p>
|
|
<ol>
|
|
<li>Tuomo Soini has supplied a correction to a problem that occurs using
|
|
some versions of 'ash'. The symptom is that "shorewall start" fails
|
|
with:<br>
|
|
<br>
|
|
local: --limit: bad variable name<br>
|
|
iptables v1.2.8: Couldn't load match
|
|
`-j':/lib/iptables/libipt_-j.so:<br>
|
|
cannot open shared object file: No such file or directory<br>
|
|
Try `iptables -h' or 'iptables --help' for more
|
|
information.<br>
|
|
<br>
|
|
</li>
|
|
<li>Andres Zhoglo has supplied a correction that avoids trying to use the
|
|
multiport match iptables facility on ICMP rules.<br>
|
|
<br>
|
|
Example of rule that previously caused "shorewall start" to
|
|
fail:<br>
|
|
<br>
|
|
|
|
ACCEPT loc $FW
|
|
icmp 0,8,11,12<br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, if the following error message was issued, Shorewall was
|
|
left in an inconsistent state.<br>
|
|
<br>
|
|
Error: Unable to determine the routes through interface
|
|
xxx<br>
|
|
<br>
|
|
</li>
|
|
<li>Handling of the LOGUNCLEAN option in shorewall.conf has been
|
|
corrected.</li>
|
|
<li>In Shorewall 1.4.2, an optimization was added. This optimization
|
|
involved creating a chain named "<zone>_frwd" for most zones
|
|
defined using the /etc/shorewall/hosts file. It has since been discovered
|
|
that in many cases these new chains contain redundant rules and that the
|
|
"optimization" turns out to be less than optimal. The implementation has
|
|
now been corrected.</li>
|
|
<li>When the MARK value in a tcrules entry is followed by ":F" or ":P", the
|
|
":F" or ":P" was previously only applied to the first Netfilter rule
|
|
generated by the entry. It is now applied to all entries.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>10/06/2003 - Shorewall 1.4.7</b><b><br>
|
|
</b></p>
|
|
<b>Problems Corrected since version 1.4.6 (Those in bold font were corrected
|
|
since 1.4.7 RC2).</b><br>
|
|
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
|
|
tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages during
|
|
"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
|
|
added to a PPP interface; the addresses were successfully added in spite
|
|
of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now displayed by
|
|
"shorewall monitor" on the "Dynamic Chains" page (previously named
|
|
"Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
|
<li value="7">The 'shorewall reject' and 'shorewall drop' commands now
|
|
delete any existing rules for the subject IP address before adding a new
|
|
DROP or REJECT rule. Previously, there could be many rules for the same
|
|
IP address in the dynamic chain so that multiple 'allow' commands were
|
|
required to re-enable traffic to/from the address.</li>
|
|
<li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in
|
|
/etc/shorewall/masq resulted in a startup error:<br>
|
|
<br>
|
|
eth0 eth1
|
|
206.124.146.20-206.124.146.24<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall previously choked over IPV6 addresses configured on
|
|
interfaces in contexts where Shorewall needed to detect something about
|
|
the interface (such as when "detect" appears in the BROADCAST column of
|
|
the /etc/shorewall/interfaces file).</li>
|
|
<li>Shorewall will now load module files that are formed from the module
|
|
name by appending ".o.gz".</li>
|
|
<li>When Shorewall adds a route to a proxy ARP host and such a route
|
|
already exists, two routes resulted previously. This has been corrected
|
|
so that the existing route is replaced if it already exists.</li>
|
|
<li>The rfc1918 file has been updated to reflect recent allocations.</li>
|
|
<li>The documentation of the USER SET column in the rules file has been
|
|
corrected.</li>
|
|
<li>If there is no policy defined for the zones specified in a rule, the
|
|
firewall script previously encountered a shell syntax error:<br>
|
|
<br>
|
|
[: NONE: unexpected
|
|
operator<br>
|
|
<br>
|
|
Now, the absence of a policy generates an error message and the firewall
|
|
is stopped:<br>
|
|
<br>
|
|
No policy defined from zone
|
|
<source> to zone <dest><br>
|
|
<br>
|
|
</li>
|
|
<li>Previously, if neither /etc/shorewall/common nor
|
|
/etc/shorewall/common.def existed, Shorewall would fail to start and
|
|
would not remove the lock file. Failure to remove the lock file resulted
|
|
in the following during subsequent attempts to start:<br>
|
|
<br>
|
|
Loading /usr/share/shorewall/functions...<br>
|
|
Processing /etc/shorewall/params ...<br>
|
|
Processing /etc/shorewall/shorewall.conf...<br>
|
|
Giving up on lock file /var/lib/shorewall/lock<br>
|
|
Shorewall Not Started<br>
|
|
<br>
|
|
Shorewall now reports a fatal error if neither of these two files exist
|
|
and correctly removes the lock fille.</li>
|
|
<li>The order of processing the various options has been changed such that
|
|
blacklist entries now take precedence over the 'dhcp' <span
|
|
style="font-weight: bold;">i</span>nterface setting.</li>
|
|
<li>The log message generated from the 'logunclean' interface option has
|
|
been changed to reflect a disposition of LOG rather than DROP.</li>
|
|
<li><span style="font-weight: bold;">When a user name and/or a group name
|
|
was specified in the USER SET column and the destination zone was
|
|
qualified with a IP address, the user and/or group name was not being
|
|
used to qualify the rule.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
ACCEPT fw net:192.0.2.12 tcp 23 - - -
|
|
vladimir:<br>
|
|
<br>
|
|
</span></li>
|
|
<li><span style="font-weight: bold;">The /etc/shorewall/masq file has had
|
|
the spurious "/" character at the front removed.<br>
|
|
<br>
|
|
</span></li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
|
|
<ol>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
|
|
see the <a href="Accounting.html">Accounting Page</a> for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has changed --
|
|
see the <a href="UserSets.html">User Set page</a> for details.</li>
|
|
<li>The per-interface Dynamic Blacklisting facility introduced in the first
|
|
post-1.4.6 Snapshot has been removed. The facility had too many
|
|
idiosyncrasies for dial-up users to be a viable part of Shorewall.<br>
|
|
</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
|
|
<ol>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of "No"
|
|
for existing users which causes Shorewall's 'stopped' state to
|
|
continue as it has been; namely, in the stopped state only traffic
|
|
to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
|
|
to traffic to/from the hosts listed in /etc/shorewall/routestopped,
|
|
Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself; and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
|
entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
|
possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp 22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
|
connection with local system 192.168.1.5. I then create a second SSH
|
|
connection from that computer to the firewall and confidently type
|
|
"shorewall stop". As part of its stop processing, Shorewall removes
|
|
eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add specific
|
|
support for all of it. I have therefore decided to add "generic" tunnel
|
|
support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel types. You
|
|
usually add a zone to represent the systems at the other end of the
|
|
tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone> <ip
|
|
address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the protocol
|
|
used by the tunnel<br>
|
|
<port> if the protocol
|
|
is 'udp' or 'tcp' then this is the destination port number used by the
|
|
tunnel.<br>
|
|
<zone> is the zone of
|
|
the remote tunnel gateway<br>
|
|
<ip address> is the IP address
|
|
of the remote tunnel gateway.<br>
|
|
<gateway zone>
|
|
Optional. A comma-separated list of zone names. If specified, the remote
|
|
gateway is to be considered part of these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
|
|
file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
|
result that this interface will only answer ARP 'who-has' requests from
|
|
hosts that are routed out through that interface. Setting this option
|
|
facilitates testing of your firewall where multiple firewall interfaces
|
|
are connected to the same HUB/Switch (all interfaces connected to the
|
|
single HUB/Switch should have this option specified). Note that using
|
|
such a configuration in a production environment is strongly recommended
|
|
against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter will
|
|
use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for traffic
|
|
accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the corresponding
|
|
ACCEPT rule in the filter table is not rate limited. If you want to limit
|
|
the filter table rule, you will need o create two rules; a DNAT- rule and
|
|
an ACCEPT rule which can be rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate limiting is
|
|
specified on a rule with "all" in the SOURCE or DEST fields, the limit
|
|
will apply to each pair of zones individually rather than as a single
|
|
limit for all pairs of covered by the rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate per
|
|
<interval><br>
|
|
<interval> is "sec" or "min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5 is
|
|
assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there may
|
|
be any white space within the burst specification. If you want to specify
|
|
logging of a rate-limited rule, the ":" and log level comes after the
|
|
">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
|
file. You may specify the rate limit there in the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted; in
|
|
fact, since the burst is 4, the first four packets will be accepted.
|
|
After this, it will be 500ms (1 second divided by the rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless of how
|
|
many packets reach it. Also, every 500ms which passes without matching a
|
|
packet, one of the bursts will be regained; if no packets hit the rule
|
|
for 2 second, the burst will be fully recharged; back where we
|
|
started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show" command
|
|
(e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited to a set
|
|
of local users and/or groups. See <a
|
|
href="UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
details.</li>
|
|
</ol>
|
|
|
|
<p><b>10/02/2003 - Shorewall 1.4.7 RC2</b><b><br>
|
|
</b></p>
|
|
|
|
<p><b><a
|
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
</b></p>
|
|
<b>Problems Corrected since version 1.4.6 (Those in bold font were corrected
|
|
since 1.4.7 RC 1).</b><br>
|
|
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
|
|
tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages during
|
|
"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
|
|
added to a PPP interface; the addresses were successfully added in spite
|
|
of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now displayed by
|
|
"shorewall monitor" on the "Dynamic Chains" page (previously named
|
|
"Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
|
<li value="7">The 'shorewall reject' and 'shorewall drop' commands now
|
|
delete any existing rules for the subject IP address before adding a new
|
|
DROP or REJECT rule. Previously, there could be many rules for the same
|
|
IP address in the dynamic chain so that multiple 'allow' commands were
|
|
required to re-enable traffic to/from the address.</li>
|
|
<li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in
|
|
/etc/shorewall/masq resulted in a startup error:<br>
|
|
<br>
|
|
eth0 eth1
|
|
206.124.146.20-206.124.146.24<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall previously choked over IPV6 addresses configured on
|
|
interfaces in contexts where Shorewall needed to detect something about
|
|
the interface (such as when "detect" appears in the BROADCAST column of
|
|
the /etc/shorewall/interfaces file).</li>
|
|
<li>Shorewall will now load module files that are formed from the module
|
|
name by appending ".o.gz".</li>
|
|
<li>When Shorewall adds a route to a proxy ARP host and such a route
|
|
already exists, two routes resulted previously. This has been corrected
|
|
so that the existing route is replaced if it already exists.</li>
|
|
<li>The rfc1918 file has been updated to reflect recent allocations.</li>
|
|
<li><span style="font-weight: bold;">The documentation of the USER SET
|
|
column in the rules file has been corrected.</span></li>
|
|
<li><span style="font-weight: bold;">If there is no policy defined for the
|
|
zones specified in a rule, the firewall script previously encountered a
|
|
shell syntax error:<br>
|
|
<br>
|
|
[: NONE: unexpected
|
|
operator<br>
|
|
<br>
|
|
Now, the absence of a policy generates an error message and the firewall
|
|
is stopped:<br>
|
|
<br>
|
|
No policy defined from zone
|
|
<source> to zone <dest><br>
|
|
<br>
|
|
</span></li>
|
|
<li><span style="font-weight: bold;">Previously, if neither
|
|
/etc/shorewall/common nor /etc/shorewall/common.def existed, Shorewall
|
|
would fail to start and would not remove the lock file. Failure to remove
|
|
the lock file resulted in the following during subsequent attempts to
|
|
start:<br>
|
|
<br>
|
|
Loading /usr/share/shorewall/functions...<br>
|
|
Processing /etc/shorewall/params ...<br>
|
|
Processing /etc/shorewall/shorewall.conf...<br>
|
|
Giving up on lock file /var/lib/shorewall/lock<br>
|
|
Shorewall Not Started<br>
|
|
<br>
|
|
Shorewall now reports a fatal error if neither of these two files exist
|
|
and correctly removes the lock fille.</span></li>
|
|
<li><span style="font-weight: bold;">The order of processing the various
|
|
options has been changed such that blacklist entries now take precedence
|
|
over the 'dhcp' interface setting.</span></li>
|
|
<li><span style="font-weight: bold;">The log message generated from the
|
|
'logunclean' interface option has been changed to reflect a disposition
|
|
of LOG rather than DROP.</span></li>
|
|
<li><span style="font-weight: bold;">The RFC1918 file has been updated to
|
|
reflect recent IANA allocations.<br>
|
|
</span></li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
|
|
<ol>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
|
|
see the <a href="Accounting.html">Accounting Page</a> for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has changed --
|
|
see the <a href="UserSets.html">User Set page</a> for details.</li>
|
|
<li>The per-interface Dynamic Blacklisting facility introduced in the first
|
|
post-1.4.6 Snapshot has been removed. The facility had too many
|
|
idiosyncrasies for dial-up users to be a viable part of Shorewall.<br>
|
|
</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
|
|
<ol>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of "No"
|
|
for existing users which causes Shorewall's 'stopped' state to
|
|
continue as it has been; namely, in the stopped state only traffic
|
|
to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
|
|
to traffic to/from the hosts listed in /etc/shorewall/routestopped,
|
|
Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself; and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
|
entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
|
possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp 22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
|
connection with local system 192.168.1.5. I then create a second SSH
|
|
connection from that computer to the firewall and confidently type
|
|
"shorewall stop". As part of its stop processing, Shorewall removes
|
|
eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add specific
|
|
support for all of it. I have therefore decided to add "generic" tunnel
|
|
support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel types. You
|
|
usually add a zone to represent the systems at the other end of the
|
|
tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone> <ip
|
|
address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the protocol
|
|
used by the tunnel<br>
|
|
<port> if the protocol
|
|
is 'udp' or 'tcp' then this is the destination port number used by the
|
|
tunnel.<br>
|
|
<zone> is the zone of
|
|
the remote tunnel gateway<br>
|
|
<ip address> is the IP address
|
|
of the remote tunnel gateway.<br>
|
|
<gateway zone>
|
|
Optional. A comma-separated list of zone names. If specified, the remote
|
|
gateway is to be considered part of these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
|
|
file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
|
result that this interface will only answer ARP 'who-has' requests from
|
|
hosts that are routed out through that interface. Setting this option
|
|
facilitates testing of your firewall where multiple firewall interfaces
|
|
are connected to the same HUB/Switch (all interfaces connected to the
|
|
single HUB/Switch should have this option specified). Note that using
|
|
such a configuration in a production environment is strongly recommended
|
|
against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter will
|
|
use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for traffic
|
|
accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the corresponding
|
|
ACCEPT rule in the filter table is not rate limited. If you want to limit
|
|
the filter table rule, you will need o create two rules; a DNAT- rule and
|
|
an ACCEPT rule which can be rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate limiting is
|
|
specified on a rule with "all" in the SOURCE or DEST fields, the limit
|
|
will apply to each pair of zones individually rather than as a single
|
|
limit for all pairs of covered by the rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate per
|
|
<interval><br>
|
|
<interval> is "sec" or "min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5 is
|
|
assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there may
|
|
be any white space within the burst specification. If you want to specify
|
|
logging of a rate-limited rule, the ":" and log level comes after the
|
|
">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
|
file. You may specify the rate limit there in the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted; in
|
|
fact, since the burst is 4, the first four packets will be accepted.
|
|
After this, it will be 500ms (1 second divided by the rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless of how
|
|
many packets reach it. Also, every 500ms which passes without matching a
|
|
packet, one of the bursts will be regained; if no packets hit the rule
|
|
for 2 second, the burst will be fully recharged; back where we
|
|
started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show" command
|
|
(e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited to a set
|
|
of local users and/or groups. See <a
|
|
href="UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
details.</li>
|
|
</ol>
|
|
|
|
<p><b>9/18/2003 - Shorewall 1.4.7 RC 1</b><b><br>
|
|
</b></p>
|
|
|
|
<p><b><a
|
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
</b></p>
|
|
<b>Problems Corrected since version 1.4.6 (Those in bold font were corrected
|
|
since 1.4.7 Beta 1).</b><br>
|
|
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
|
|
tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages during
|
|
"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
|
|
added to a PPP interface; the addresses were successfully added in spite
|
|
of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now displayed by
|
|
"shorewall monitor" on the "Dynamic Chains" page (previously named
|
|
"Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
|
<li value="7">The 'shorewall reject' and 'shorewall drop' commands now
|
|
delete any existing rules for the subject IP address before adding a new
|
|
DROP or REJECT rule. Previously, there could be many rules for the same
|
|
IP address in the dynamic chain so that multiple 'allow' commands were
|
|
required to re-enable traffic to/from the address.</li>
|
|
<li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in
|
|
/etc/shorewall/masq resulted in a startup error:<br>
|
|
<br>
|
|
eth0 eth1
|
|
206.124.146.20-206.124.146.24<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall previously choked over IPV6 addresses configured on
|
|
interfaces in contexts where Shorewall needed to detect something about
|
|
the interface (such as when "detect" appears in the BROADCAST column of
|
|
the /etc/shorewall/interfaces file).</li>
|
|
<li>Shorewall will now load module files that are formed from the module
|
|
name by appending ".o.gz".</li>
|
|
<li style="font-weight: bold;">When Shorewall adds a route to a proxy ARP
|
|
host and such a route already exists, two routes resulted previously.
|
|
This has been corrected so that the existing route is replaced if it
|
|
already exists.</li>
|
|
<li><span style="font-weight: bold;">The rfc1918 file has been updated to
|
|
reflect recent allocations.</span><br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
|
|
<ol>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
|
|
see the <a href="Accounting.html">Accounting Page</a> for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has changed --
|
|
see the <a href="UserSets.html">User Set page</a> for details.</li>
|
|
<li>The per-interface Dynamic Blacklisting facility introduced in the first
|
|
post-1.4.6 Snapshot has been removed. The facility had too many
|
|
idiosyncrasies for dial-up users to be a viable part of Shorewall.<br>
|
|
</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
|
|
<ol>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of "No"
|
|
for existing users which causes Shorewall's 'stopped' state to
|
|
continue as it has been; namely, in the stopped state only traffic
|
|
to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
|
|
to traffic to/from the hosts listed in /etc/shorewall/routestopped,
|
|
Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself; and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
|
entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
|
possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp 22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
|
connection with local system 192.168.1.5. I then create a second SSH
|
|
connection from that computer to the firewall and confidently type
|
|
"shorewall stop". As part of its stop processing, Shorewall removes
|
|
eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add specific
|
|
support for all of it. I have therefore decided to add "generic" tunnel
|
|
support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel types. You
|
|
usually add a zone to represent the systems at the other end of the
|
|
tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone> <ip
|
|
address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the protocol
|
|
used by the tunnel<br>
|
|
<port> if the protocol
|
|
is 'udp' or 'tcp' then this is the destination port number used by the
|
|
tunnel.<br>
|
|
<zone> is the zone of
|
|
the remote tunnel gateway<br>
|
|
<ip address> is the IP address
|
|
of the remote tunnel gateway.<br>
|
|
<gateway zone>
|
|
Optional. A comma-separated list of zone names. If specified, the remote
|
|
gateway is to be considered part of these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
|
|
file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
|
result that this interface will only answer ARP 'who-has' requests from
|
|
hosts that are routed out through that interface. Setting this option
|
|
facilitates testing of your firewall where multiple firewall interfaces
|
|
are connected to the same HUB/Switch (all interfaces connected to the
|
|
single HUB/Switch should have this option specified). Note that using
|
|
such a configuration in a production environment is strongly recommended
|
|
against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter will
|
|
use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for traffic
|
|
accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the corresponding
|
|
ACCEPT rule in the filter table is not rate limited. If you want to limit
|
|
the filter table rule, you will need o create two rules; a DNAT- rule and
|
|
an ACCEPT rule which can be rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate limiting is
|
|
specified on a rule with "all" in the SOURCE or DEST fields, the limit
|
|
will apply to each pair of zones individually rather than as a single
|
|
limit for all pairs of covered by the rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate per
|
|
<interval><br>
|
|
<interval> is "sec" or "min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5 is
|
|
assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there may
|
|
be any white space within the burst specification. If you want to specify
|
|
logging of a rate-limited rule, the ":" and log level comes after the
|
|
">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
|
file. You may specify the rate limit there in the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted; in
|
|
fact, since the burst is 4, the first four packets will be accepted.
|
|
After this, it will be 500ms (1 second divided by the rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless of how
|
|
many packets reach it. Also, every 500ms which passes without matching a
|
|
packet, one of the bursts will be regained; if no packets hit the rule
|
|
for 2 second, the burst will be fully recharged; back where we
|
|
started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show" command
|
|
(e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited to a set
|
|
of local users and/or groups. See <a
|
|
href="UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
details.</li>
|
|
</ol>
|
|
|
|
<p><b>9/15/2003 - Shorewall 1.4.7 Beta 2</b> <b><br>
|
|
</b></p>
|
|
|
|
<p><b><a
|
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
</b></p>
|
|
<b>Problems Corrected since version 1.4.6 (Those in bold font were corrected
|
|
since 1.4.7 Beta 1).</b><br>
|
|
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
|
|
tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages during
|
|
"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
|
|
added to a PPP interface; the addresses were successfully added in spite
|
|
of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now displayed by
|
|
"shorewall monitor" on the "Dynamic Chains" page (previously named
|
|
"Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.</li>
|
|
<li value="7" style="font-weight: bold;">The 'shorewall reject' and
|
|
'shorewall drop' commands now delete any existing rules for the subject
|
|
IP address before adding a new DROP or REJECT rule. Previously, there
|
|
could be many rules for the same IP address in the dynamic chain so that
|
|
multiple 'allow' commands were required to re-enable traffic to/from the
|
|
address.</li>
|
|
<li style="font-weight: bold;">When ADD_SNAT_ALIASES=Yes in shorewall.conf,
|
|
the following entry in /etc/shorewall/masq resulted in a startup
|
|
error:<br>
|
|
<br>
|
|
eth0 eth1
|
|
206.124.146.20-206.124.146.24<br>
|
|
<br>
|
|
</li>
|
|
<li style="font-weight: bold;">Shorewall previously choked over IPV6
|
|
addresses configured on interfaces in contexts where Shorewall needed to
|
|
detect something about the interface (such as when "detect" appears in
|
|
the BROADCAST column of the /etc/shorewall/interfaces file).</li>
|
|
<li><span style="font-weight: bold;">Shorewall will now load module files
|
|
that are formed from the module name by appending ".o.gz".</span><br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
|
|
<ol>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
|
|
see the <a href="Accounting.html">Accounting Page</a> for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has changed --
|
|
see the <a href="UserSets.html">User Set page</a> for details.</li>
|
|
<li>The per-interface Dynamic Blacklisting facility introduced in the first
|
|
post-1.4.6 Snapshot has been removed. The facility had too many
|
|
idiosyncrasies for dial-up users to be a viable part of Shorewall.<br>
|
|
</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
|
|
<ol>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of "No"
|
|
for existing users which causes Shorewall's 'stopped' state to
|
|
continue as it has been; namely, in the stopped state only traffic
|
|
to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
|
|
to traffic to/from the hosts listed in /etc/shorewall/routestopped,
|
|
Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself; and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
|
entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
|
possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp 22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
|
connection with local system 192.168.1.5. I then create a second SSH
|
|
connection from that computer to the firewall and confidently type
|
|
"shorewall stop". As part of its stop processing, Shorewall removes
|
|
eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add specific
|
|
support for all of it. I have therefore decided to add "generic" tunnel
|
|
support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel types. You
|
|
usually add a zone to represent the systems at the other end of the
|
|
tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone> <ip
|
|
address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the protocol
|
|
used by the tunnel<br>
|
|
<port> if the protocol
|
|
is 'udp' or 'tcp' then this is the destination port number used by the
|
|
tunnel.<br>
|
|
<zone> is the zone of
|
|
the remote tunnel gateway<br>
|
|
<ip address> is the IP address
|
|
of the remote tunnel gateway.<br>
|
|
<gateway zone>
|
|
Optional. A comma-separated list of zone names. If specified, the remote
|
|
gateway is to be considered part of these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
|
|
file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
|
result that this interface will only answer ARP 'who-has' requests from
|
|
hosts that are routed out through that interface. Setting this option
|
|
facilitates testing of your firewall where multiple firewall interfaces
|
|
are connected to the same HUB/Switch (all interfaces connected to the
|
|
single HUB/Switch should have this option specified). Note that using
|
|
such a configuration in a production environment is strongly recommended
|
|
against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter will
|
|
use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for traffic
|
|
accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the corresponding
|
|
ACCEPT rule in the filter table is not rate limited. If you want to limit
|
|
the filter table rule, you will need o create two rules; a DNAT- rule and
|
|
an ACCEPT rule which can be rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate limiting is
|
|
specified on a rule with "all" in the SOURCE or DEST fields, the limit
|
|
will apply to each pair of zones individually rather than as a single
|
|
limit for all pairs of covered by the rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate per
|
|
<interval><br>
|
|
<interval> is "sec" or "min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5 is
|
|
assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there may
|
|
be any white space within the burst specification. If you want to specify
|
|
logging of a rate-limited rule, the ":" and log level comes after the
|
|
">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
|
file. You may specify the rate limit there in the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted; in
|
|
fact, since the burst is 4, the first four packets will be accepted.
|
|
After this, it will be 500ms (1 second divided by the rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless of how
|
|
many packets reach it. Also, every 500ms which passes without matching a
|
|
packet, one of the bursts will be regained; if no packets hit the rule
|
|
for 2 second, the burst will be fully recharged; back where we
|
|
started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show" command
|
|
(e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited to a set
|
|
of local users and/or groups. See <a
|
|
href="UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
details.</li>
|
|
</ol>
|
|
|
|
<p><b>8/27/2003 - Shorewall Mirror in Australia</b></p>
|
|
|
|
<p>Thanks to Dave Kempe and Solutions First (<a
|
|
href="http://www.solutionsfirst.com.au"><font
|
|
size="3">http://www.solutionsfirst.com.au</font></a>), there is now a
|
|
Shorewall Mirror in Australia:</p>
|
|
|
|
<div style="margin-left: 40px;">
|
|
<a href="http://www.shorewall.com.au" target="_top"><font
|
|
size="3">http://www.shorewall.com.au</font></a><br>
|
|
<a href="ftp://ftp.shorewall.com.au"><font
|
|
size="3">ftp://ftp.shorewall.com.au</font></a> </div>
|
|
|
|
<p><b>8/26/2003 - French Version of the Shorewall Setup Guide </b></p>
|
|
Thanks to Fabien <font size="3">Demassieux, there is now a <a
|
|
href="shorewall_setup_guide_fr.htm">French translation of the Shorewall Setup
|
|
Guide</a>. Merci Beacoup, Fabien!</font>
|
|
|
|
<p><b>8/25/2003 - Shorewall 1.4.7 Beta 1</b> <b><br>
|
|
</b></p>
|
|
|
|
<p><b><a
|
|
href="http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Beta"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
|
|
</b></p>
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
|
|
tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages during
|
|
"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
|
|
added to a PPP interface; the addresses were successfully added in spite
|
|
of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now displayed by
|
|
"shorewall monitor" on the "Dynamic Chains" page (previously named
|
|
"Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.<br>
|
|
<br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
|
|
<ol>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
|
|
see the <a href="Accounting.html">Accounting Page</a> for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has changed --
|
|
see the <a href="UserSets.html">User Set page</a> for details.</li>
|
|
<li>The per-interface Dynamic Blacklisting facility introduced in the first
|
|
post-1.4.6 Snapshot has been removed. The facility had too many
|
|
idiosyncrasies for dial-up users to be a viable part of Shorewall.<br>
|
|
</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
|
|
<ol>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of "No"
|
|
for existing users which causes Shorewall's 'stopped' state to
|
|
continue as it has been; namely, in the stopped state only traffic
|
|
to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
|
|
to traffic to/from the hosts listed in /etc/shorewall/routestopped,
|
|
Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself; and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
|
entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
|
possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp 22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
|
connection with local system 192.168.1.5. I then create a second SSH
|
|
connection from that computer to the firewall and confidently type
|
|
"shorewall stop". As part of its stop processing, Shorewall removes
|
|
eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add specific
|
|
support for all of it. I have therefore decided to add "generic" tunnel
|
|
support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel types. You
|
|
usually add a zone to represent the systems at the other end of the
|
|
tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone> <ip
|
|
address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the protocol
|
|
used by the tunnel<br>
|
|
<port> if the protocol
|
|
is 'udp' or 'tcp' then this is the destination port number used by the
|
|
tunnel.<br>
|
|
<zone> is the zone of
|
|
the remote tunnel gateway<br>
|
|
<ip address> is the IP address
|
|
of the remote tunnel gateway.<br>
|
|
<gateway zone>
|
|
Optional. A comma-separated list of zone names. If specified, the remote
|
|
gateway is to be considered part of these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
|
|
file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
|
result that this interface will only answer ARP 'who-has' requests from
|
|
hosts that are routed out through that interface. Setting this option
|
|
facilitates testing of your firewall where multiple firewall interfaces
|
|
are connected to the same HUB/Switch (all interfaces connected to the
|
|
single HUB/Switch should have this option specified). Note that using
|
|
such a configuration in a production environment is strongly recommended
|
|
against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter will
|
|
use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for traffic
|
|
accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the corresponding
|
|
ACCEPT rule in the filter table is not rate limited. If you want to limit
|
|
the filter table rule, you will need o create two rules; a DNAT- rule and
|
|
an ACCEPT rule which can be rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate limiting is
|
|
specified on a rule with "all" in the SOURCE or DEST fields, the limit
|
|
will apply to each pair of zones individually rather than as a single
|
|
limit for all pairs of covered by the rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate per
|
|
<interval><br>
|
|
<interval> is "sec" or "min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5 is
|
|
assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there may
|
|
be any white space within the burst specification. If you want to specify
|
|
logging of a rate-limited rule, the ":" and log level comes after the
|
|
">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
|
file. You may specify the rate limit there in the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted; in
|
|
fact, since the burst is 4, the first four packets will be accepted.
|
|
After this, it will be 500ms (1 second divided by the rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless of how
|
|
many packets reach it. Also, every 500ms which passes without matching a
|
|
packet, one of the bursts will be regained; if no packets hit the rule
|
|
for 2 second, the burst will be fully recharged; back where we
|
|
started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show" command
|
|
(e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited to a set
|
|
of local users and/or groups. See <a
|
|
href="UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
details.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>8/23/2003 - Snapshot 1.4.6_2003082</b><span
|
|
style="font-weight: bold;">3</span></p>
|
|
|
|
<blockquote>
|
|
<p><a
|
|
href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
</blockquote>
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
|
|
tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages during
|
|
"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
|
|
added to a PPP interface; the addresses were successfully added in spite
|
|
of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error messages</li>
|
|
<li>Interface-specific dynamic blacklisting chains are now displayed by
|
|
"shorewall monitor" on the "Dynamic Chains" page (previously named
|
|
"Dynamic Chain").</li>
|
|
<li>Thanks to Henry Yang, LOGRATE and LOGBURST now work again.<br>
|
|
<br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
|
|
<ol>
|
|
<li>Once you have installed this version of Shorewall, you must restart
|
|
Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
|
|
commands.</li>
|
|
<li>To maintain strict compatibility with previous versions, current uses
|
|
of "shorewall drop" and "shorewall reject" should be replaced with
|
|
"shorewall dropall" and "shorewall rejectall"</li>
|
|
<li>Shorewall IP Traffic Accounting has changed since snapshot 20030813 --
|
|
see the <a href="Accounting.html">Accounting Page</a> for details.</li>
|
|
<li>The Uset Set capability introduced in SnapShot 20030821 has changed --
|
|
see the <a href="UserSets.html">User Set page</a> for details.</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
|
|
<ol>
|
|
<li>Shorewall now creates a dynamic blacklisting chain for each interface
|
|
defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
|
|
use the routing table to determine which of these chains is to be used
|
|
for blacklisting the specified IP address(es).<br>
|
|
<br>
|
|
Two new commands ('dropall' and 'rejectall') have been introduced that do
|
|
what 'drop' and 'reject' used to do; namely, when an address is
|
|
blacklisted using these new commands, it will be blacklisted on all of
|
|
your firewall's interfaces.</li>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of "No"
|
|
for existing users which causes Shorewall's 'stopped' state to
|
|
continue as it has been; namely, in the stopped state only traffic
|
|
to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
|
|
to traffic to/from the hosts listed in /etc/shorewall/routestopped,
|
|
Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself; and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
|
entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
|
possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp 22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
|
connection with local system 192.168.1.5. I then create a second SSH
|
|
connection from that computer to the firewall and confidently type
|
|
"shorewall stop". As part of its stop processing, Shorewall removes
|
|
eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add specific
|
|
support for all of it. I have therefore decided to add "generic" tunnel
|
|
support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel types. You
|
|
usually add a zone to represent the systems at the other end of the
|
|
tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone> <ip
|
|
address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the protocol
|
|
used by the tunnel<br>
|
|
<port> if the protocol
|
|
is 'udp' or 'tcp' then this is the destination port number used by the
|
|
tunnel.<br>
|
|
<zone> is the zone of
|
|
the remote tunnel gateway<br>
|
|
<ip address> is the IP address
|
|
of the remote tunnel gateway.<br>
|
|
<gateway zone>
|
|
Optional. A comma-separated list of zone names. If specified, the remote
|
|
gateway is to be considered part of these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
|
|
file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
|
result that this interface will only answer ARP 'who-has' requests from
|
|
hosts that are routed out through that interface. Setting this option
|
|
facilitates testing of your firewall where multiple firewall interfaces
|
|
are connected to the same HUB/Switch (all interfaces connected to the
|
|
single HUB/Switch should have this option specified). Note that using
|
|
such a configuration in a production environment is strongly recommended
|
|
against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter will
|
|
use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for traffic
|
|
accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the corresponding
|
|
ACCEPT rule in the filter table is not rate limited. If you want to limit
|
|
the filter table rule, you will need o create two rules; a DNAT- rule and
|
|
an ACCEPT rule which can be rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate limiting is
|
|
specified on a rule with "all" in the SOURCE or DEST fields, the limit
|
|
will apply to each pair of zones individually rather than as a single
|
|
limit for all pairs of covered by the rule.<br>
|
|
<br>
|
|
To specify a rate limit,<br>
|
|
<br>
|
|
a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate per
|
|
<interval><br>
|
|
<interval> is "sec" or "min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5 is
|
|
assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there may
|
|
be any white space within the burst specification. If you want to specify
|
|
logging of a rate-limited rule, the ":" and log level comes after the
|
|
">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
|
|
file. You may specify the rate limit there in the format:<br>
|
|
<br>
|
|
|
|
<rate>/<interval>[:<burst>]<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted; in
|
|
fact, since the burst is 4, the first four packets will be accepted.
|
|
After this, it will be 500ms (1 second divided by the rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless of how
|
|
many packets reach it. Also, every 500ms which passes without matching a
|
|
packet, one of the bursts will be regained; if no packets hit the rule
|
|
for 2 second, the burst will be fully recharged; back where we
|
|
started.<br>
|
|
</li>
|
|
<li>Multiple chains may now be displayed in one "shorewall show" command
|
|
(e.g., shorewall show INPUT FORWARD OUTPUT).</li>
|
|
<li>Output rules (those with $FW as the SOURCE) may now be limited to a set
|
|
of local users and/or groups. See <a
|
|
href="UserSets.html">http://shorewall.net/UserSets.html</a> for
|
|
details.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>8/13/2003 - Snapshot 1.4.6_20030813</b><b> </b></p>
|
|
|
|
<blockquote>
|
|
<p><a
|
|
href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
</blockquote>
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
|
|
tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages during
|
|
"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
|
|
added to a PPP interface; the addresses were successfully added in spite
|
|
of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error messages</li>
|
|
<li> Interface-specific dynamic blacklisting chains are now displayed
|
|
by "shorewall monitor" on the "Dynamic Chains" page (previously named
|
|
"Dynamic Chain").<br>
|
|
<br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
|
|
<ol>
|
|
<li>Once you have installed this version of Shorewall, you must restart
|
|
Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
|
|
commands.</li>
|
|
<li>To maintain strict compatibility with previous versions, current uses
|
|
of "shorewall drop" and "shorewall reject" should be replaced with
|
|
"shorewall dropall" and "shorewall rejectall"</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
|
|
<ol>
|
|
<li>Shorewall now creates a dynamic blacklisting chain for each interface
|
|
defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
|
|
use the routing table to determine which of these chains is to be used
|
|
for blacklisting the specified IP address(es).<br>
|
|
<br>
|
|
Two new commands ('dropall' and 'rejectall') have been introduced that do
|
|
what 'drop' and 'reject' used to do; namely, when an address is
|
|
blacklisted using these new commands, it will be blacklisted on all of
|
|
your firewall's interfaces.</li>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of "No"
|
|
for existing users which causes Shorewall's 'stopped' state to
|
|
continue as it has been; namely, in the stopped state only traffic
|
|
to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
|
|
to traffic to/from the hosts listed in /etc/shorewall/routestopped,
|
|
Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself; and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
|
entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
|
possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp 22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
|
connection with local system 192.168.1.5. I then create a second SSH
|
|
connection from that computer to the firewall and confidently type
|
|
"shorewall stop". As part of its stop processing, Shorewall removes
|
|
eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add specific
|
|
support for all of it. I have therefore decided to add "generic" tunnel
|
|
support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel types. You
|
|
usually add a zone to represent the systems at the other end of the
|
|
tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone> <ip
|
|
address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the protocol
|
|
used by the tunnel<br>
|
|
<port> if the protocol
|
|
is 'udp' or 'tcp' then this is the destination port number used by the
|
|
tunnel.<br>
|
|
<zone> is the zone of
|
|
the remote tunnel gateway<br>
|
|
<ip address> is the IP address
|
|
of the remote tunnel gateway.<br>
|
|
<gateway zone>
|
|
Optional. A comma-separated list of zone names. If specified, the remote
|
|
gateway is to be considered part of these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
|
|
file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
|
result that this interface will only answer ARP 'who-has' requests from
|
|
hosts that are routed out through that interface. Setting this option
|
|
facilitates testing of your firewall where multiple firewall interfaces
|
|
are connected to the same HUB/Switch (all interfaces connected to the
|
|
single HUB/Switch should have this option specified). Note that using
|
|
such a configuration in a production environment is strongly recommended
|
|
against.</li>
|
|
<li>The ADDRESS column in /etc/shorewall/masq may now include a
|
|
comma-separated list of addresses and/or address ranges. Netfilter will
|
|
use all listed addresses/ranges in round-robin fashion. \</li>
|
|
<li>An /etc/shorewall/accounting file has been added to allow for traffic
|
|
accounting. See the <a href="Accounting.html">accounting
|
|
documentation</a> for a description of this facility.</li>
|
|
<li>Bridge interfaces (br[0-9]) may now be used in
|
|
/etc/shorewall/maclist.</li>
|
|
<li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
|
|
/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
|
|
rules, rate limiting occurs in the nat table DNAT rule; the corresponding
|
|
ACCEPT rule in the filter table is not rate limited. If you want to limit
|
|
the filter table rule, you will need o create two rules; a DNAT- rule and
|
|
an ACCEPT rule which can be rate-limited separately.<br>
|
|
<br>
|
|
<span style="font-weight: bold;">Warning:</span> When rate limiting is
|
|
specified on a rule with "all" in the SOURCE or DEST fields, the limit
|
|
will apply to each pair of zones individually rather than as a single
|
|
limit for all pairs of covered by the rule.<br>
|
|
<br>
|
|
To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-] or LOG
|
|
with<br>
|
|
<br>
|
|
<
|
|
<rate>/<interval>[:<burst>] ><br>
|
|
<br>
|
|
where<br>
|
|
<br>
|
|
<rate> is the sustained rate per
|
|
<interval><br>
|
|
<interval> is "sec" or "min"<br>
|
|
<burst> is the largest burst
|
|
accepted within an <interval>. If not given, the default of 5 is
|
|
assumed.<br>
|
|
<br>
|
|
There may be no white space between the ACTION and "<" nor there may
|
|
be any white space within the burst specification. If you want to specify
|
|
logging of a rate-limited rule, the ":" and log level comes after the
|
|
">" (e.g., ACCEPT<2/sec:4>:info ).<br>
|
|
<br>
|
|
Let's take an example:<br>
|
|
<br>
|
|
|
|
ACCEPT<2/sec:4>
|
|
net dmz
|
|
tcp 80<br>
|
|
<br>
|
|
The first time this rule is reached, the packet will be accepted; in
|
|
fact, since the burst is 4, the first four packets will be accepted.
|
|
After this, it will be 500ms (1 second divided by the rate<br>
|
|
of 2) before a packet will be accepted from this rule, regardless of how
|
|
many packets reach it. Also, every 500ms which passes without matching a
|
|
packet, one of the bursts will be regained; if no packets hit the rule
|
|
for 2 second, the burst will be fully recharged; back where we
|
|
started.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>8/9/2003 - Snapshot 1.4.6_20030809</b><b> </b></p>
|
|
|
|
<blockquote>
|
|
<p><a
|
|
href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
</blockquote>
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
|
|
tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages during
|
|
"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
|
|
added to a PPP interface; the addresses were successfully added in spite
|
|
of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error messages<br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
|
|
<ol>
|
|
<li>Once you have installed this version of Shorewall, you must restart
|
|
Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
|
|
commands.</li>
|
|
<li>To maintain strict compatibility with previous versions, current uses
|
|
of "shorewall drop" and "shorewall reject" should be replaced with
|
|
"shorewall dropall" and "shorewall rejectall"</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
|
|
<ol>
|
|
<li>Shorewall now creates a dynamic blacklisting chain for each interface
|
|
defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
|
|
use the routing table to determine which of these chains is to be used
|
|
for blacklisting the specified IP address(es).<br>
|
|
<br>
|
|
Two new commands ('dropall' and 'rejectall') have been introduced that do
|
|
what 'drop' and 'reject' used to do; namely, when an address is
|
|
blacklisted using these new commands, it will be blacklisted on all of
|
|
your firewall's interfaces.</li>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of "No"
|
|
for existing users which causes Shorewall's 'stopped' state to
|
|
continue as it has been; namely, in the stopped state only traffic
|
|
to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
|
|
to traffic to/from the hosts listed in /etc/shorewall/routestopped,
|
|
Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself; and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
|
entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
|
possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp 22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
|
connection with local system 192.168.1.5. I then create a second SSH
|
|
connection from that computer to the firewall and confidently type
|
|
"shorewall stop". As part of its stop processing, Shorewall removes
|
|
eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
|
|
<li>Given the wide range of VPN software, I can never hope to add specific
|
|
support for all of it. I have therefore decided to add "generic" tunnel
|
|
support.<br>
|
|
<br>
|
|
Generic tunnels work pretty much like any of the other tunnel types. You
|
|
usually add a zone to represent the systems at the other end of the
|
|
tunnel and you add the appropriate rules/policies to<br>
|
|
implement your security policy regarding traffic to/from those
|
|
systems.<br>
|
|
<br>
|
|
In the /etc/shorewall/tunnels file, you can have entries of the form:<br>
|
|
<br>
|
|
generic:<protocol>[:<port>] <zone> <ip
|
|
address> <gateway zones><br>
|
|
<br>
|
|
where:<br>
|
|
<br>
|
|
<protocol> is the protocol
|
|
used by the tunnel<br>
|
|
<port> if the protocol
|
|
is 'udp' or 'tcp' then this is the destination port number used by the
|
|
tunnel.<br>
|
|
<zone> is the zone of
|
|
the remote tunnel gateway<br>
|
|
<ip address> is the IP address
|
|
of the remote tunnel gateway.<br>
|
|
<gateway zone>
|
|
Optional. A comma-separated list of zone names. If specified, the remote
|
|
gateway is to be considered part of these zones.</li>
|
|
<li>An 'arp_filter' option has been added to the /etc/shorewall/interfaces
|
|
file. This option causes
|
|
/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
|
|
result that this interface will only answer ARP 'who-has' requests from
|
|
hosts that are routed out through that interface. Setting this option
|
|
facilitates testing of your firewall where multiple firewall interfaces
|
|
are connected to the same HUB/Switch (all interfaces connected to the
|
|
single HUB/Switch should have this option specified). Note that using
|
|
such a configuration in a production environment is strongly recommended
|
|
against.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>8/5/2003 - Shorewall-1.4.6b</b><b> <br>
|
|
</b></p>
|
|
<b>Problems Corrected since version 1.4.6:</b><br>
|
|
|
|
<ol>
|
|
<li>Previously, if TC_ENABLED is set to yes in shorewall.conf then
|
|
Shorewall would fail to start with the error "ERROR: Traffic
|
|
Control requires Mangle"; that problem has been corrected.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages during
|
|
"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
|
|
added to a PPP interface; the addresses were successfully added in spite
|
|
of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error
|
|
messages.</li>
|
|
</ol>
|
|
|
|
<p><b>8/5/2003 - Shorewall-1.4.6b</b> <b><br>
|
|
</b></p>
|
|
<b>Problems Corrected since version 1.4.6:</b><br>
|
|
|
|
<ol>
|
|
<li>Previously, if TC_ENABLED is set to yes in shorewall.conf then
|
|
Shorewall would fail to start with the error "ERROR: Traffic
|
|
Control requires Mangle"; that problem has been corrected.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.</li>
|
|
<li>The "shorewall stop" command is now disabled when
|
|
/etc/shorewall/startup_disabled exists. This prevents people from
|
|
shooting themselves in the foot prior to having configured Shorewall.</li>
|
|
<li>A change introduced in version 1.4.6 caused error messages during
|
|
"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were being
|
|
added to a PPP interface; the addresses were successfully added in spite
|
|
of the messages.<br>
|
|
<br>
|
|
The firewall script has been modified to eliminate the error messages.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>7/31/2003 - Snapshot 1.4.6_20030731</b></p>
|
|
|
|
<blockquote>
|
|
<p><a
|
|
href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
</blockquote>
|
|
|
|
<p><b>Problems Corrected since version 1.4.6:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
|
|
tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>Migration Issues:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>Once you have installed this version of Shorewall, you must restart
|
|
Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
|
|
commands.</li>
|
|
<li>To maintain strict compatibility with previous versions, current uses
|
|
of "shorewall drop" and "shorewall reject" should be replaced with
|
|
"shorewall dropall" and "shorewall rejectall"</li>
|
|
</ol>
|
|
|
|
<p><b>New Features:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>Shorewall now creates a dynamic blacklisting chain for each interface
|
|
defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
|
|
use the routing table to determine which of these chains is to be used
|
|
for blacklisting the specified IP address(es).<br>
|
|
<br>
|
|
Two new commands ('dropall' and 'rejectall') have been introduced that do
|
|
what 'drop' and 'reject' used to do; namely, when an address is
|
|
blacklisted using these new commands, it will be blacklisted on all of
|
|
your firewall's interfaces.</li>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).</li>
|
|
<li>A new option "ADMINISABSENTMINDED" has been added to
|
|
/etc/shorewall/shorewall.conf. This option has a default value of "No"
|
|
for existing users which causes Shorewall's 'stopped' state to
|
|
continue as it has been; namely, in the stopped state only traffic
|
|
to/from hosts listed in /etc/shorewall/routestopped is accepted.<br>
|
|
<br>
|
|
With ADMINISABSENTMINDED=Yes (the default for new installs), in addition
|
|
to traffic to/from the hosts listed in /etc/shorewall/routestopped,
|
|
Shorewall will allow:<br>
|
|
<br>
|
|
a) All traffic originating from the firewall itself; and<br>
|
|
b) All traffic that is part of or related to an
|
|
already-existing connection.<br>
|
|
<br>
|
|
In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
|
|
entered through an ssh session will not kill the session.<br>
|
|
<br>
|
|
Note though that even with ADMINISABSENTMINDED=Yes, it is still
|
|
possible for people to shoot themselves in the foot.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
/etc/shorewall/nat:<br>
|
|
<br>
|
|
206.124.146.178
|
|
eth0:0 192.168.1.5 <br>
|
|
<br>
|
|
/etc/shorewall/rules:<br>
|
|
<br>
|
|
ACCEPT net
|
|
loc:192.168.1.5 tcp 22<br>
|
|
ACCEPT loc
|
|
fw tcp 22<br>
|
|
<br>
|
|
From a remote system, I ssh to 206.124.146.178 which establishes an SSH
|
|
connection with local system 192.168.1.5. I then create a second SSH
|
|
connection from that computer to the firewall and confidently type
|
|
"shorewall stop". As part of its stop processing, Shorewall removes
|
|
eth0:0 which kills my SSH connection to 192.168.1.5!!!</li>
|
|
</ol>
|
|
|
|
<p><b>7/27/2003 - Snapshot 1.4.6_20030727</b></p>
|
|
|
|
<blockquote>
|
|
<p><a
|
|
href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
</blockquote>
|
|
<b>Problems Corrected since version 1.4.6</b><br>
|
|
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
|
|
tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.<br>
|
|
</li>
|
|
</ol>
|
|
<b>Migration Issues:</b><br>
|
|
|
|
<ol>
|
|
<li>Once you have installed this version of Shorewall, you must restart
|
|
Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
|
|
commands.</li>
|
|
<li>To maintain strict compatibility with previous versions, current uses
|
|
of "shorewall drop" and "shorewall reject" should be replaced with
|
|
"shorewall dropall" and "shorewall rejectall"</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
|
|
<ol>
|
|
<li>Shorewall now creates a dynamic blacklisting chain for each interface
|
|
defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands
|
|
use the routing table to determine which of these chains is to be used
|
|
for blacklisting the specified IP address(es).<br>
|
|
<br>
|
|
Two new commands ('dropall' and 'rejectall') have been introduced that do
|
|
what 'drop' and 'reject' used to do; namely, when an address is
|
|
blacklisted using these new commands, it will be blacklisted on all of
|
|
your firewall's interfaces.</li>
|
|
<li>Thanks to Steve Herber, the 'help' command can now give
|
|
command-specific help (e.g., shorewall help <command>).<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>7/26/2003 - Snapshot 1.4.6_20030726</b></p>
|
|
|
|
<blockquote>
|
|
<p><a
|
|
href="http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>
|
|
<a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
|
|
target="_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
|
|
</blockquote>
|
|
|
|
<p><b>Problems Corrected since version 1.4.6:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was being
|
|
tested before it was set.</li>
|
|
<li>Corrected handling of MAC addresses in the SOURCE column of the tcrules
|
|
file. Previously, these addresses resulted in an invalid iptables
|
|
command.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>Migration Issues:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>Once you have installed this version of Shorewall, you must restart
|
|
Shorewall before you may use the 'drop', 'reject', 'allow' or 'save'
|
|
commands.</li>
|
|
<li>To maintain strict compatibility with previous versions, current uses
|
|
of "shorewall drop" and "shorewall reject" should be replaced with
|
|
"shorewall dropall" and "shorewall rejectall"</li>
|
|
</ol>
|
|
|
|
<p><b>New Features:</b><br>
|
|
</p>
|
|
Shorewall now creates a dynamic blacklisting chain for each interface defined
|
|
in /etc/shorewall/interfaces. The 'drop' and 'reject' commands use the
|
|
routing table to determine which of these chains is to be used for
|
|
blacklisting the specified IP address(es).<br>
|
|
<br>
|
|
Two new commands ('dropall' and 'rejectall') have been introduced that do
|
|
what 'drop' and 'reject' used to do; namely, when an address is blacklisted
|
|
using these new commands, it will be blacklisted on all of your firewall's
|
|
interfaces.
|
|
|
|
<p><b>7/22/2003 - Shorewall-1.4.6a</b> <b><br>
|
|
</b></p>
|
|
<b>Problems Corrected:</b><br>
|
|
|
|
<ol>
|
|
<li>Previously, if TC_ENABLED is set to yes in shorewall.conf then
|
|
Shorewall would fail to start with the error "ERROR: Traffic
|
|
Control requires Mangle"; that problem has been corrected.</li>
|
|
</ol>
|
|
|
|
<p><b>7/20/2003 - Shorewall-1.4.6</b> <b><br>
|
|
</b></p>
|
|
|
|
<p><b>Problems Corrected:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A problem seen on RH7.3 systems where Shorewall encountered start
|
|
errors when started using the "service" mechanism has been worked
|
|
around.<br>
|
|
<br>
|
|
</li>
|
|
<li>Where a list of IP addresses appears in the DEST column of a DNAT[-]
|
|
rule, Shorewall incorrectly created multiple DNAT rules in the nat table
|
|
(one for each element in the list). Shorewall now correctly creates a
|
|
single DNAT rule with multiple "--to-destination" clauses.<br>
|
|
<br>
|
|
</li>
|
|
<li>Corrected a problem in Beta 1 where DNS names containing a "-" were
|
|
mis-handled when they appeared in the DEST column of a rule.<br>
|
|
<br>
|
|
</li>
|
|
<li>A number of problems with rule parsing have been corrected. Corrections
|
|
involve the handling of "z1!z2" in the SOURCE column as well as lists in
|
|
the ORIGINAL DESTINATION column.<br>
|
|
<br>
|
|
</li>
|
|
<li>The message "Adding rules for DHCP" is now suppressed if there are no
|
|
DHCP rules to add.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>Migration Issues:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>In earlier versions, an undocumented feature allowed entries in the
|
|
host file as follows:<br>
|
|
<br>
|
|
z
|
|
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
|
<br>
|
|
This capability was never documented and has been removed in 1.4.6 to
|
|
allow entries of the following format:<br>
|
|
<br>
|
|
z eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
|
|
from /etc/shorewall/shorewall.conf. These capabilities are now
|
|
automatically detected by Shorewall (see below).<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>New Features:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A 'newnotsyn' interface option has been added. This option may be
|
|
specified in /etc/shorewall/interfaces and overrides the setting
|
|
NEWNOTSYN=No for packets arriving on the associated interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>The means for specifying a range of IP addresses in /etc/shorewall/masq
|
|
to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
|
|
address ranges.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall can now add IP addresses to subnets other than the first one
|
|
on an interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>DNAT[-] rules may now be used to load balance (round-robin) over a set
|
|
of servers. Servers may be specified in a range of addresses given as
|
|
<first address>-<last address>.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
|
|
have been removed and have been replaced by code that detects whether
|
|
these capabilities are present in the current kernel. The output of the
|
|
start, restart and check commands have been enhanced to report the
|
|
outcome:<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for the Connection Tracking Match Extension has been added.
|
|
This extension is available in recent kernel/iptables releases and allows
|
|
for rules which match against elements in netfilter's connection tracking
|
|
table. Shorewall automatically detects the availability of this extension
|
|
and reports its availability in the output of the start, restart and
|
|
check commands.<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Connection Tracking Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
If this extension is available, the ruleset generated by Shorewall is
|
|
changed in the following ways:</li>
|
|
<li
|
|
style="list-style-type: none; list-style-position: outside; list-style-image: none;"><ul>
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not create chains
|
|
in the mangle table but will rather do all 'norfc1918' filtering in
|
|
the filter table (rfc1918 chain).</li>
|
|
<li>Recall that Shorewall DNAT rules generate two netfilter rules; one
|
|
in the nat table and one in the filter table. If the Connection
|
|
Tracking Match Extension is available, the rule in the filter table
|
|
is extended to check that the original destination address was the
|
|
same as specified (or defaulted to) in the DNAT rule.<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>The shell used to interpret the firewall script
|
|
(/usr/share/shorewall/firewall) may now be specified using the
|
|
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
ipcalc [ <address> <netmask> |
|
|
<address>/<vlsm> ]<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0/24<br>
|
|
CIDR=192.168.1.0/24<br>
|
|
NETMASK=255.255.255.0<br>
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0 255.255.255.0<br>
|
|
CIDR=192.168.1.0/24<br>
|
|
NETMASK=255.255.255.0<br>
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
Warning:<br>
|
|
<br>
|
|
If your shell only supports 32-bit signed arithmatic (ash or dash), then
|
|
the ipcalc command produces incorrect information for IP addresses
|
|
128.0.0.0-1 and for /1 networks. Bash should produce correct information
|
|
for all valid IP addresses.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'iprange' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
iprange <address>-<address><br>
|
|
<br>
|
|
This command decomposes a range of IP addressses into a list of network
|
|
and host addresses. The command can be useful if you need to construct an
|
|
efficient set of rules that accept connections from a range of network
|
|
addresses.<br>
|
|
<br>
|
|
Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
|
|
then the range may not span 128.0.0.0.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
[root@gateway root]# shorewall iprange
|
|
192.168.1.4-192.168.12.9<br>
|
|
192.168.1.4/30<br>
|
|
192.168.1.8/29<br>
|
|
192.168.1.16/28<br>
|
|
192.168.1.32/27<br>
|
|
192.168.1.64/26<br>
|
|
192.168.1.128/25<br>
|
|
192.168.2.0/23<br>
|
|
192.168.4.0/22<br>
|
|
192.168.8.0/22<br>
|
|
192.168.12.0/29<br>
|
|
192.168.12.8/31<br>
|
|
[root@gateway root]#<br>
|
|
<br>
|
|
</li>
|
|
<li>A list of host/net addresses is now allowed in an entry in
|
|
/etc/shorewall/hosts.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
foo
|
|
eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
<br>
|
|
</li>
|
|
<li>The "shorewall check" command now includes the chain name when printing
|
|
the applicable policy for each pair of zones.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
Policy for dmz to net is
|
|
REJECT using chain all2all<br>
|
|
<br>
|
|
This means that the policy for connections from the dmz to the internet
|
|
is REJECT and the applicable entry in the /etc/shorewall/policy was the
|
|
all->all policy.<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for the 2.6 Kernel series has been added.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>7/15/2003 - New Mirror in Brazil</b><b><br>
|
|
</b></p>
|
|
Thanks to the folks at securityopensource.org.br, there is now a <a
|
|
href="http://shorewall.securityopensource.org.br" target="_top">Shorewall
|
|
mirror in Brazil</a>.
|
|
|
|
<p><b>7/15/2003 - Shorewall-1.4.6 RC 1</b> <b><br>
|
|
</b></p>
|
|
|
|
<p><b>Problems Corrected:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A problem seen on RH7.3 systems where Shorewall encountered start
|
|
errors when started using the "service" mechanism has been worked
|
|
around.<br>
|
|
<br>
|
|
</li>
|
|
<li>Where a list of IP addresses appears in the DEST column of a DNAT[-]
|
|
rule, Shorewall incorrectly created multiple DNAT rules in the nat table
|
|
(one for each element in the list). Shorewall now correctly creates a
|
|
single DNAT rule with multiple "--to-destination" clauses.<br>
|
|
<br>
|
|
</li>
|
|
<li>Corrected a problem in Beta 1 where DNS names containing a "-" were
|
|
mis-handled when they appeared in the DEST column of a rule.<br>
|
|
<br>
|
|
</li>
|
|
<li>A number of problems with rule parsing have been corrected. Corrections
|
|
involve the handling of "z1!z2" in the SOURCE column as well as lists in
|
|
the ORIGINAL DESTINATION column.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>Migration Issues:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>In earlier versions, an undocumented feature allowed entries in the
|
|
host file as follows:<br>
|
|
<br>
|
|
z
|
|
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
|
<br>
|
|
This capability was never documented and has been removed in 1.4.6 to
|
|
allow entries of the following format:<br>
|
|
<br>
|
|
z eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
|
|
from /etc/shorewall/shorewall.conf. These capabilities are now
|
|
automatically detected by Shorewall (see below).<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>New Features:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A 'newnotsyn' interface option has been added. This option may be
|
|
specified in /etc/shorewall/interfaces and overrides the setting
|
|
NEWNOTSYN=No for packets arriving on the associated interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>The means for specifying a range of IP addresses in /etc/shorewall/masq
|
|
to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
|
|
address ranges.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall can now add IP addresses to subnets other than the first one
|
|
on an interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>DNAT[-] rules may now be used to load balance (round-robin) over a set
|
|
of servers. Servers may be specified in a range of addresses given as
|
|
<first address>-<last address>.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
|
|
have been removed and have been replaced by code that detects whether
|
|
these capabilities are present in the current kernel. The output of the
|
|
start, restart and check commands have been enhanced to report the
|
|
outcome:<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for the Connection Tracking Match Extension has been added.
|
|
This extension is available in recent kernel/iptables releases and allows
|
|
for rules which match against elements in netfilter's connection tracking
|
|
table. Shorewall automatically detects the availability of this extension
|
|
and reports its availability in the output of the start, restart and
|
|
check commands.<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Connection Tracking Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
If this extension is available, the ruleset generated by Shorewall is
|
|
changed in the following ways:</li>
|
|
<li
|
|
style="list-style-type: none; list-style-position: outside; list-style-image: none;"><ul>
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not create chains
|
|
in the mangle table but will rather do all 'norfc1918' filtering in
|
|
the filter table (rfc1918 chain).</li>
|
|
<li>Recall that Shorewall DNAT rules generate two netfilter rules; one
|
|
in the nat table and one in the filter table. If the Connection
|
|
Tracking Match Extension is available, the rule in the filter table
|
|
is extended to check that the original destination address was the
|
|
same as specified (or defaulted to) in the DNAT rule.<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>The shell used to interpret the firewall script
|
|
(/usr/share/shorewall/firewall) may now be specified using the
|
|
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
ipcalc [ <address> <netmask> |
|
|
<address>/<vlsm> ]<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0/24<br>
|
|
CIDR=192.168.1.0/24<br>
|
|
NETMASK=255.255.255.0<br>
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0 255.255.255.0<br>
|
|
CIDR=192.168.1.0/24<br>
|
|
NETMASK=255.255.255.0<br>
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
Warning:<br>
|
|
<br>
|
|
If your shell only supports 32-bit signed arithmatic (ash or dash), then
|
|
the ipcalc command produces incorrect information for IP addresses
|
|
128.0.0.0-1 and for /1 networks. Bash should produce correct information
|
|
for all valid IP addresses.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'iprange' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
iprange <address>-<address><br>
|
|
<br>
|
|
This command decomposes a range of IP addressses into a list of network
|
|
and host addresses. The command can be useful if you need to construct an
|
|
efficient set of rules that accept connections from a range of network
|
|
addresses.<br>
|
|
<br>
|
|
Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
|
|
then the range may not span 128.0.0.0.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
[root@gateway root]# shorewall iprange
|
|
192.168.1.4-192.168.12.9<br>
|
|
192.168.1.4/30<br>
|
|
192.168.1.8/29<br>
|
|
192.168.1.16/28<br>
|
|
192.168.1.32/27<br>
|
|
192.168.1.64/26<br>
|
|
192.168.1.128/25<br>
|
|
192.168.2.0/23<br>
|
|
192.168.4.0/22<br>
|
|
192.168.8.0/22<br>
|
|
192.168.12.0/29<br>
|
|
192.168.12.8/31<br>
|
|
[root@gateway root]#<br>
|
|
<br>
|
|
</li>
|
|
<li>A list of host/net addresses is now allowed in an entry in
|
|
/etc/shorewall/hosts.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
foo
|
|
eth1:192.168.1.0/24,192.168.2.0/24</li>
|
|
</ol>
|
|
|
|
<p><b>7/7/2003 - Shorewall-1.4.6 Beta 2</b></p>
|
|
|
|
<p><b>Problems Corrected:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A problem seen on RH7.3 systems where Shorewall encountered start
|
|
errors when started using the "service" mechanism has been worked
|
|
around.<br>
|
|
<br>
|
|
</li>
|
|
<li>Where a list of IP addresses appears in the DEST column of a DNAT[-]
|
|
rule, Shorewall incorrectly created multiple DNAT rules in the nat table
|
|
(one for each element in the list). Shorewall now correctly creates a
|
|
single DNAT rule with multiple "--to-destination" clauses.<br>
|
|
<br>
|
|
</li>
|
|
<li>Corrected a problem in Beta 1 where DNS names containing a "-" were
|
|
mis-handled when they appeared in the DEST column of a rule.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>Migration Issues:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>In earlier versions, an undocumented feature allowed entries in the
|
|
host file as follows:<br>
|
|
<br>
|
|
z
|
|
eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
|
<br>
|
|
This capability was never documented and has been removed in 1.4.6 to
|
|
allow entries of the following format:<br>
|
|
<br>
|
|
z eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
|
|
from /etc/shorewall/shorewall.conf. These capabilities are now
|
|
automatically detected by Shorewall (see below).<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>New Features:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A 'newnotsyn' interface option has been added. This option may be
|
|
specified in /etc/shorewall/interfaces and overrides the setting
|
|
NEWNOTSYN=No for packets arriving on the associated interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>The means for specifying a range of IP addresses in /etc/shorewall/masq
|
|
to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
|
|
address ranges.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall can now add IP addresses to subnets other than the first one
|
|
on an interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>DNAT[-] rules may now be used to load balance (round-robin) over a set
|
|
of servers. Servers may be specified in a range of addresses given as
|
|
<first address>-<last address>.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
|
|
have been removed and have been replaced by code that detects whether
|
|
these capabilities are present in the current kernel. The output of the
|
|
start, restart and check commands have been enhanced to report the
|
|
outcome:<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for the Connection Tracking Match Extension has been added.
|
|
This extension is available in recent kernel/iptables releases and allows
|
|
for rules which match against elements in netfilter's connection tracking
|
|
table. Shorewall automatically detects the availability of this extension
|
|
and reports its availability in the output of the start, restart and
|
|
check commands.<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Connection Tracking Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
If this extension is available, the ruleset generated by Shorewall is
|
|
changed in the following ways:</li>
|
|
<li
|
|
style="list-style-type: none; list-style-position: outside; list-style-image: none;"><ul>
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not create chains
|
|
in the mangle table but will rather do all 'norfc1918' filtering in
|
|
the filter table (rfc1918 chain).</li>
|
|
<li>Recall that Shorewall DNAT rules generate two netfilter rules; one
|
|
in the nat table and one in the filter table. If the Connection
|
|
Tracking Match Extension is available, the rule in the filter table
|
|
is extended to check that the original destination address was the
|
|
same as specified (or defaulted to) in the DNAT rule.<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>The shell used to interpret the firewall script
|
|
(/usr/share/shorewall/firewall) may now be specified using the
|
|
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
ipcalc [ <address> <netmask> |
|
|
<address>/<vlsm> ]<br>
|
|
<br>
|
|
Examples:<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0/24<br>
|
|
CIDR=192.168.1.0/24<br>
|
|
NETMASK=255.255.255.0<br>
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
[root@wookie root]# shorewall ipcalc
|
|
192.168.1.0 255.255.255.0<br>
|
|
CIDR=192.168.1.0/24<br>
|
|
NETMASK=255.255.255.0<br>
|
|
NETWORK=192.168.1.0<br>
|
|
|
|
BROADCAST=192.168.1.255<br>
|
|
[root@wookie root]#<br>
|
|
<br>
|
|
Warning:<br>
|
|
<br>
|
|
If your shell only supports 32-bit signed arithmatic (ash or dash), then
|
|
the ipcalc command produces incorrect information for IP addresses
|
|
128.0.0.0-1 and for /1 networks. Bash should produce correct information
|
|
for all valid IP addresses.<br>
|
|
<br>
|
|
</li>
|
|
<li>An 'iprange' command has been added to /sbin/shorewall.<br>
|
|
<br>
|
|
iprange <address>-<address><br>
|
|
<br>
|
|
This command decomposes a range of IP addressses into a list of network
|
|
and host addresses. The command can be useful if you need to construct an
|
|
efficient set of rules that accept connections from a range of network
|
|
addresses.<br>
|
|
<br>
|
|
Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
|
|
then the range may not span 128.0.0.0.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
[root@gateway root]# shorewall iprange
|
|
192.168.1.4-192.168.12.9<br>
|
|
192.168.1.4/30<br>
|
|
192.168.1.8/29<br>
|
|
192.168.1.16/28<br>
|
|
192.168.1.32/27<br>
|
|
192.168.1.64/26<br>
|
|
192.168.1.128/25<br>
|
|
192.168.2.0/23<br>
|
|
192.168.4.0/22<br>
|
|
192.168.8.0/22<br>
|
|
192.168.12.0/29<br>
|
|
192.168.12.8/31<br>
|
|
[root@gateway root]#<br>
|
|
<br>
|
|
</li>
|
|
<li>A list of host/net addresses is now allowed in an entry in
|
|
/etc/shorewall/hosts.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
foo
|
|
eth1:192.168.1.0/24,192.168.2.0/24<br>
|
|
<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>7/4/2003 - Shorewall-1.4.6 Beta 1</b></p>
|
|
|
|
<p><b>Problems Corrected:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A problem seen on RH7.3 systems where Shorewall encountered start
|
|
errors when started using the "service" mechanism has been worked
|
|
around.<br>
|
|
<br>
|
|
</li>
|
|
<li>Where a list of IP addresses appears in the DEST column of a DNAT[-]
|
|
rule, Shorewall incorrectly created multiple DNAT rules in the nat table
|
|
(one for each element in the list). Shorewall now correctly creates a
|
|
single DNAT rule with multiple "--to-destination" clauses.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>New Features:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>A 'newnotsyn' interface option has been added. This option may be
|
|
specified in /etc/shorewall/interfaces and overrides the setting
|
|
NEWNOTSYN=No for packets arriving on the associated interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>The means for specifying a range of IP addresses in /etc/shorewall/masq
|
|
to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for
|
|
address ranges.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall can now add IP addresses to subnets other than the first one
|
|
on an interface.<br>
|
|
<br>
|
|
</li>
|
|
<li>DNAT[-] rules may now be used to load balance (round-robin) over a set
|
|
of servers. Up to 256 servers may be specified in a range of addresses
|
|
given as <first address>-<last address>.<br>
|
|
<br>
|
|
Example:<br>
|
|
<br>
|
|
DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
|
|
<br>
|
|
Note that this capability has previously been available using a
|
|
combination of a DNAT- rule and one or more ACCEPT rules. That technique
|
|
is still preferable for load-balancing over a large number of servers
|
|
(> 16) since specifying a range in the DNAT rule causes one filter
|
|
table ACCEPT rule to be generated for each IP address in the range.<br>
|
|
<br>
|
|
</li>
|
|
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
|
|
have been removed and have been replaced by code that detects whether
|
|
these capabilities are present in the current kernel. The output of the
|
|
start, restart and check commands have been enhanced to report the
|
|
outcome:<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for the Connection Tracking Match Extension has been added.
|
|
This extension is available in recent kernel/iptables releases and allows
|
|
for rules which match against elements in netfilter's connection tracking
|
|
table. Shorewall automatically detects the availability of this extension
|
|
and reports its availability in the output of the start, restart and
|
|
check commands.<br>
|
|
<br>
|
|
Shorewall has detected the following iptables/netfilter capabilities:<br>
|
|
NAT: Available<br>
|
|
Packet Mangling: Available<br>
|
|
Multi-port Match: Available<br>
|
|
Connection Tracking Match: Available<br>
|
|
Verifying Configuration...<br>
|
|
<br>
|
|
If this extension is available, the ruleset generated by Shorewall is
|
|
changed in the following ways:</li>
|
|
<li
|
|
style="list-style-type: none; list-style-position: outside; list-style-image: none;"><ul>
|
|
<li>To handle 'norfc1918' filtering, Shorewall will not create chains
|
|
in the mangle table but will rather do all 'norfc1918' filtering in
|
|
the filter table (rfc1918 chain).</li>
|
|
<li>Recall that Shorewall DNAT rules generate two netfilter rules; one
|
|
in the nat table and one in the filter table. If the Connection
|
|
Tracking Match Extension is available, the rule in the filter table
|
|
is extended to check that the original destination address was the
|
|
same as specified (or defaulted to) in the DNAT rule.<br>
|
|
<br>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>The shell used to interpret the firewall script
|
|
(/usr/share/shorewall/firewall) may now be specified using the
|
|
SHOREWALL_SHELL parameter in shorewall.conf.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>6/17/2003 - Shorewall-1.4.5</b></p>
|
|
|
|
<p>Problems Corrected:<br>
|
|
</p>
|
|
<ol>
|
|
<li>The command "shorewall debug try <directory>" now correctly
|
|
traces the attempt.</li>
|
|
<li>The INCLUDE directive now works properly in the zones file; previously,
|
|
INCLUDE in that file was ignored.</li>
|
|
<li>/etc/shorewall/routestopped records with an empty second column are no
|
|
longer ignored.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>New Features:<br>
|
|
</p>
|
|
<ol>
|
|
<li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now
|
|
contain a list of addresses. If the list begins with "!' then the rule
|
|
will take effect only if the original destination address in the
|
|
connection request does not match any of the addresses listed.</li>
|
|
</ol>
|
|
|
|
<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8</b></p>
|
|
|
|
<p>The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and
|
|
iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems
|
|
have been encountered with this set of software. The Shorewall version is
|
|
1.4.4b plus the accumulated changes for 1.4.5.<br>
|
|
</p>
|
|
|
|
<p><b>6/8/2003 - Updated Samples</b></p>
|
|
|
|
<p>Thanks to Francesca Smith, the samples have been updated to Shorewall
|
|
version 1.4.4.</p>
|
|
|
|
<p><b>5/29/2003 - Shorewall-1.4.4b</b></p>
|
|
|
|
<p>Groan -- This version corrects a problem whereby the --log-level was not
|
|
being set when logging via syslog. The most commonly reported symptom was
|
|
that Shorewall messages were being written to the console even though console
|
|
logging was correctly configured per FAQ 16.<br>
|
|
</p>
|
|
|
|
<p><b>5/27/2003 - Shorewall-1.4.4a</b></p>
|
|
The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out that
|
|
the code in 1.4.4 restricts the length of short zone names to 4 characters.
|
|
I've produced version 1.4.4a that restores the previous 5-character limit by
|
|
conditionally omitting the log rule number when the LOGFORMAT doesn't contain
|
|
'%d'. <br>
|
|
|
|
|
|
<p><b>5/23/2003 - Shorewall-1.4.4</b></p>
|
|
I apologize for the rapid-fire releases but since there is a potential
|
|
configuration change required to go from 1.4.3a to 1.4.4, I decided to make
|
|
it a full release rather than just a bug-fix release. <br>
|
|
<br>
|
|
<b> Problems corrected:</b><br>
|
|
|
|
|
|
<blockquote>
|
|
None.<br>
|
|
</blockquote>
|
|
<b> New Features:<br>
|
|
</b>
|
|
<ol>
|
|
<li>A REDIRECT- rule target has been added. This target behaves for
|
|
REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter nat
|
|
table REDIRECT rule is added but not the companion filter table ACCEPT
|
|
rule.<br>
|
|
<br>
|
|
</li>
|
|
<li>The LOGMARKER variable has been renamed LOGFORMAT and has been changed
|
|
to a 'printf' formatting template which accepts three arguments (the
|
|
chain name, logging rule number and the disposition). To use LOGFORMAT
|
|
with fireparse (<a
|
|
href="http://www.fireparse.com">http://www.fireparse.com</a>), set it
|
|
as:<br>
|
|
<br>
|
|
LOGFORMAT="fp=%s:%d a=%s "<br>
|
|
<br>
|
|
<b>CAUTION:</b> /sbin/shorewall uses the leading part of the LOGFORMAT
|
|
string (up to but not including the first '%') to find log messages in
|
|
the 'show log', 'status' and 'hits' commands. This part should not be
|
|
omitted (the LOGFORMAT should not begin with "%") and the leading part
|
|
should be sufficiently unique for /sbin/shorewall to identify Shorewall
|
|
messages.<br>
|
|
<br>
|
|
</li>
|
|
<li>When logging is specified on a DNAT[-] or REDIRECT[-] rule, the logging
|
|
now takes place in the nat table rather than in the filter table. This
|
|
way, only those connections that actually undergo DNAT or redirection
|
|
will be logged.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>5/20/2003 - Shorewall-1.4.3a</b><br>
|
|
</p>
|
|
This version primarily corrects the documentation included in the .tgz and in
|
|
the .rpm. In addition: <br>
|
|
|
|
<ol>
|
|
<li>(This change is in 1.4.3 but is not documented) If you are running
|
|
iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject
|
|
replies as follows:<br>
|
|
a) tcp - RST<br>
|
|
b) udp - ICMP port unreachable<br>
|
|
c) icmp - ICMP host unreachable<br>
|
|
d) Otherwise - ICMP host prohibited<br>
|
|
If you are running earlier software, Shorewall will follow it's
|
|
traditional convention:<br>
|
|
a) tcp - RST<br>
|
|
b) Otherwise - ICMP port unreachable</li>
|
|
<li>UDP port 135 is now silently dropped in the common.def chain. Remember
|
|
that this chain is traversed just before a DROP or REJECT policy is
|
|
enforced.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>5/18/2003 - Shorewall 1.4.3</b><br>
|
|
</p>
|
|
<b>Problems Corrected:<br>
|
|
</b>
|
|
<ol>
|
|
<li>There were several cases where Shorewall would fail to remove a
|
|
temporary directory from /tmp. These cases have been corrected.</li>
|
|
<li>The rules for allowing all traffic via the loopback interface have been
|
|
moved to before the rule that drops status=INVALID packets. This insures
|
|
that all loopback traffic is allowed even if Netfilter connection
|
|
tracking is confused.</li>
|
|
</ol>
|
|
<b>New Features:<br>
|
|
</b>
|
|
<ol>
|
|
<li> IPV6-IPV4 (6to4) tunnels are now supported in the
|
|
/etc/shorewall/tunnels file.</li>
|
|
<li value="2">You may now change the leading portion of the --log-prefix
|
|
used by Shorewall using the LOGMARKER variable in shorewall.conf. By
|
|
default, "Shorewall:" is used.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>5/10/2003 - Shorewall Mirror in Asia<br>
|
|
</b></p>
|
|
|
|
<p>Ed Greshko has established a mirror in Taiwan -- Thanks Ed!<br>
|
|
</p>
|
|
|
|
<p><b>5/8/2003 - Shorewall Mirror in Chile</b></p>
|
|
Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.
|
|
|
|
<p><b>4/21/2003 - Samples updated for Shorewall version 1.4.2</b></p>
|
|
|
|
<p>Thanks to Francesca Smith, the sample configurations are now upgraded to
|
|
Shorewall version 1.4.2.</p>
|
|
|
|
<p><b>4/9/2003 - Shorewall 1.4.2</b><br>
|
|
</p>
|
|
|
|
<p><b> Problems Corrected:</b></p>
|
|
|
|
<blockquote>
|
|
<ol>
|
|
<li>TCP connection requests rejected out of the <b>common</b> chain are
|
|
now properly rejected with TCP RST; previously, some of these requests
|
|
were rejected with an ICMP port-unreachable response.</li>
|
|
<li>'traceroute -I' from behind the firewall previously timed out on the
|
|
first hop (e.g., to the firewall). This has been worked around.</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<p><b> New Features:</b></p>
|
|
<ol>
|
|
<li>Where an entry in the/etc/shorewall/hosts file specifies a particular
|
|
host or network, Shorewall now creates an intermediate chain for handling
|
|
input from the related zone. This can substantially reduce the number of
|
|
rules traversed by connections requests from such zones.<br>
|
|
<br>
|
|
</li>
|
|
<li>Any file may include an INCLUDE directive. An INCLUDE directive
|
|
consists of the word INCLUDE followed by a file name and causes the
|
|
contents of the named file to be logically included into the file
|
|
containing the INCLUDE. File names given in an INCLUDE directive are
|
|
assumed to reside in /etc/shorewall or in an alternate configuration
|
|
directory if one has been specified for the command.<br>
|
|
<br>
|
|
Examples:<br>
|
|
shorewall/params.mgmt:<br>
|
|
MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3<br>
|
|
TIME_SERVERS=4.4.4.4<br>
|
|
BACKUP_SERVERS=5.5.5.5<br>
|
|
----- end params.mgmt -----<br>
|
|
<br>
|
|
<br>
|
|
shorewall/params:<br>
|
|
# Shorewall 1.3 /etc/shorewall/params<br>
|
|
[..]<br>
|
|
#######################################<br>
|
|
<br>
|
|
INCLUDE params.mgmt <br>
|
|
<br>
|
|
# params unique to this host here<br>
|
|
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT
|
|
REMOVE<br>
|
|
----- end params -----<br>
|
|
<br>
|
|
<br>
|
|
shorewall/rules.mgmt:<br>
|
|
ACCEPT
|
|
net:$MGMT_SERVERS
|
|
$FW tcp 22<br>
|
|
ACCEPT
|
|
$FW
|
|
net:$TIME_SERVERS udp 123<br>
|
|
ACCEPT
|
|
$FW
|
|
net:$BACKUP_SERVERS tcp 22<br>
|
|
----- end rules.mgmt -----<br>
|
|
<br>
|
|
shorewall/rules:<br>
|
|
# Shorewall version 1.3 - Rules File<br>
|
|
[..]<br>
|
|
#######################################<br>
|
|
<br>
|
|
INCLUDE rules.mgmt <br>
|
|
<br>
|
|
# rules unique to this host here<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT
|
|
REMOVE<br>
|
|
----- end rules -----<br>
|
|
<br>
|
|
INCLUDE's may be nested to a level of 3 -- further nested INCLUDE
|
|
directives are ignored with a warning message.<br>
|
|
<br>
|
|
</li>
|
|
<li>Routing traffic from an interface back out that interface continues to
|
|
be a problem. While I firmly believe that this should never happen,
|
|
people continue to want to do it. To limit the damage that such nonsense
|
|
produces, I have added a new 'routeback' option in
|
|
/etc/shorewall/interfaces and /etc/shorewall/hosts. When used in
|
|
/etc/shorewall/interfaces, the 'ZONE' column may not contain '-'; in
|
|
other words, 'routeback' can't be used as an option for a multi-zone
|
|
interface. The 'routeback' option CAN be specified however on individual
|
|
group entries in /etc/shorewall/hosts.<br>
|
|
<br>
|
|
The 'routeback' option is similar to the old 'multi' option with two
|
|
exceptions:<br>
|
|
<br>
|
|
a) The option pertains to a particular
|
|
zone,interface,address tuple.<br>
|
|
<br>
|
|
b) The option only created infrastructure to pass traffic
|
|
from (zone,interface,address) tuples back to themselves (the 'multi'
|
|
option affected all (zone,interface,address) tuples associated with the
|
|
given 'interface').<br>
|
|
<br>
|
|
See the '<a href="upgrade_issues.htm">Upgrade Issues</a>' for information
|
|
about how this new option may affect your configuration.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>3/24/2003 - Shorewall 1.4.1</b></p>
|
|
|
|
<p>This release follows up on 1.4.0. It corrects a problem introduced in
|
|
1.4.0 and removes additional warts.<br>
|
|
<br>
|
|
<b>Problems Corrected:</b><br>
|
|
</p>
|
|
<ol>
|
|
<li>When Shorewall 1.4.0 is run under the ash shell (such as on
|
|
Bering/LEAF), it can attempt to add ECN disabling rules even if the
|
|
/etc/shorewall/ecn file is empty. That problem has been corrected so that
|
|
ECN disabling rules are only added if there are entries in
|
|
/etc/shorewall/ecn.</li>
|
|
</ol>
|
|
<b>New Features:</b><br>
|
|
|
|
|
|
<blockquote>
|
|
Note: In the list that follows, the term <i>group</i> 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:<br>
|
|
|
|
|
|
<blockquote>
|
|
eth0:0.0.0.0/0<br>
|
|
eth2:192.168.1.0/24<br>
|
|
eth3:192.0.2.123<br>
|
|
</blockquote>
|
|
You can use the "shorewall check" command to see the groups associated with
|
|
each of your zones.<br>
|
|
</blockquote>
|
|
<ol>
|
|
<li>Beginning with Shorewall 1.4.1, if a zone Z comprises more than one
|
|
group then if there is no explicit Z to Z policy and there are no rules
|
|
governing traffic from Z to Z then Shorewall will permit all traffic
|
|
between the groups in the zone.</li>
|
|
<li>Beginning with Shorewall 1.4.1, Shorewall will never create rules to
|
|
handle traffic from a group to itself.</li>
|
|
<li>A NONE policy is introduced in 1.4.1. When a policy of NONE is
|
|
specified from Z1 to Z2:</li>
|
|
</ol>
|
|
<ul>
|
|
<li>There may be no rules created that govern connections from Z1 to
|
|
Z2.</li>
|
|
<li>Shorewall will not create any infrastructure to handle traffic from Z1
|
|
to Z2.</li>
|
|
</ul>
|
|
See the <a href="upgrade_issues.htm">upgrade issues</a> for a discussion of
|
|
how these changes may affect your configuration.
|
|
|
|
<p><b>3/17/2003 - Shorewall 1.4.0</b></p>
|
|
Shorewall 1.4 represents the next step in the evolution of Shorewall. The
|
|
main thrust of the initial release is simply to remove the cruft that has
|
|
accumulated in Shorewall over time. <br>
|
|
<br>
|
|
<b>IMPORTANT: Shorewall 1.4.0 requires</b> <b>the iproute package ('ip'
|
|
utility).</b><br>
|
|
<br>
|
|
Function from 1.3 that has been omitted from this version include:<br>
|
|
|
|
<ol>
|
|
<li>The MERGE_HOSTS variable in shorewall.conf is no longer supported.
|
|
Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.<br>
|
|
<br>
|
|
</li>
|
|
<li>Interface names of the form <device>:<integer> in
|
|
/etc/shorewall/interfaces now generate an error.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No.
|
|
OLD_PING_HANDLING=Yes will generate an error at startup as will
|
|
specification of the 'noping' or 'filterping' interface options.<br>
|
|
<br>
|
|
</li>
|
|
<li>The 'routestopped' option in the /etc/shorewall/interfaces and
|
|
/etc/shorewall/hosts files is no longer supported and will generate an
|
|
error at startup if specified.<br>
|
|
<br>
|
|
</li>
|
|
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
|
|
accepted.<br>
|
|
<br>
|
|
</li>
|
|
<li>The ALLOWRELATED variable in shorewall.conf is no longer supported.
|
|
Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
|
|
<br>
|
|
</li>
|
|
<li>The icmp.def file has been removed.<br>
|
|
</li>
|
|
</ol>
|
|
Changes for 1.4 include:<br>
|
|
|
|
<ol>
|
|
<li>The /etc/shorewall/shorewall.conf file has been completely reorganized
|
|
into logical sections.<br>
|
|
<br>
|
|
</li>
|
|
<li>LOG is now a valid action for a rule (/etc/shorewall/rules).<br>
|
|
<br>
|
|
</li>
|
|
<li>The firewall script and version file are now installed in
|
|
/usr/share/shorewall.<br>
|
|
<br>
|
|
</li>
|
|
<li>Late arriving DNS replies are now silently dropped in the common chain
|
|
by default.<br>
|
|
<br>
|
|
</li>
|
|
<li>In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 no
|
|
longer unconditionally accepts outbound ICMP packets. So if you want to
|
|
'ping' from the firewall, you will need the appropriate rule or
|
|
policy.<br>
|
|
<br>
|
|
</li>
|
|
<li>CONTINUE is now a valid action for a rule (/etc/shorewall/rules).<br>
|
|
<br>
|
|
</li>
|
|
<li>802.11b devices with names of the form wlan<n> now support the
|
|
'maclist' option.<br>
|
|
<br>
|
|
</li>
|
|
<li>Explicit Congestion Notification (ECN - RFC 3168) may now be turned off
|
|
on a host or network basis using the new /etc/shorewall/ecn file. To use
|
|
this facility:<br>
|
|
<br>
|
|
a) You must be running kernel 2.4.20<br>
|
|
b) You must have applied the patch in<br>
|
|
http://www.shorewall/net/pub/shorewall/ecn/patch.<br>
|
|
c) You must have iptables 1.2.7a installed.<br>
|
|
<br>
|
|
</li>
|
|
<li>The /etc/shorewall/params file is now processed first so that variables
|
|
may be used in the /etc/shorewall/shorewall.conf file.<br>
|
|
<br>
|
|
</li>
|
|
<li value="10">Shorewall now gives a more helpful diagnostic when the
|
|
'ipchains' compatibility kernel module is loaded and a 'shorewall start'
|
|
command is issued.<br>
|
|
<br>
|
|
</li>
|
|
<li>The SHARED_DIR variable has been removed from shorewall.conf. This
|
|
variable was for use by package maintainers and was not documented for
|
|
general use.<br>
|
|
<br>
|
|
</li>
|
|
<li>Shorewall now ignores 'default' routes when detecting masq'd
|
|
networks.</li>
|
|
</ol>
|
|
|
|
<p><b>3/10/2003 - Shoreall 1.3.14a</b></p>
|
|
|
|
<p>A roleup of the following bug fixes and other updates:</p>
|
|
<ul>
|
|
<li>There is an updated rfc1918 file that reflects the resent allocation of
|
|
222.0.0.0/8 and 223.0.0.0/8.</li>
|
|
</ul>
|
|
<ul>
|
|
<li>The documentation for the routestopped file claimed that a
|
|
comma-separated list could appear in the second column while the code
|
|
only supported a single host or network address.</li>
|
|
<li>Log messages produced by 'logunclean' and 'dropunclean' were not
|
|
rate-limited.</li>
|
|
<li>802.11b devices with names of the form <i>wlan</i><n> don't
|
|
support the 'maclist' interface option.</li>
|
|
<li>Log messages generated by RFC 1918 filtering are not rate limited.</li>
|
|
<li>The firewall fails to start in the case where you have "eth0 eth1" in
|
|
/etc/shorewall/masq and the default route is through eth1</li>
|
|
</ul>
|
|
|
|
<p><b>2/8/2003 - Shoreawall 1.3.14</b></p>
|
|
|
|
<p>New features include</p>
|
|
<ol>
|
|
<li>An OLD_PING_HANDLING option has been added to shorewall.conf. When set
|
|
to Yes, Shorewall ping handling is as it has always been (see
|
|
http://www.shorewall.net/ping.html).<br>
|
|
<br>
|
|
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
|
|
policies just like any other connection request. The FORWARDPING=Yes
|
|
option in shorewall.conf and the 'noping' and 'filterping' options in
|
|
/etc/shorewall/interfaces will all generate an error.<br>
|
|
<br>
|
|
</li>
|
|
<li>It is now possible to direct Shorewall to create a "label" such
|
|
as "eth0:0" for IP addresses that it creates under
|
|
ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying
|
|
the label instead of just the interface name:<br>
|
|
<br>
|
|
a) In the INTERFACE column of /etc/shorewall/masq<br>
|
|
b) In the INTERFACE column of /etc/shorewall/nat<br>
|
|
</li>
|
|
<li>Support for OpenVPN Tunnels.<br>
|
|
<br>
|
|
</li>
|
|
<li>Support for VLAN devices with names of the form $DEV.$VID (e.g.,
|
|
eth0.0)<br>
|
|
<br>
|
|
</li>
|
|
<li>In /etc/shorewall/tcrules, the MARK value may be optionally followed by
|
|
":" and either 'F' or 'P' to designate that the marking will occur in the
|
|
FORWARD or PREROUTING chains respectively. If this additional
|
|
specification is omitted, the chain used to mark packets will be
|
|
determined by the setting of the MARK_IN_FORWARD_CHAIN option in <a
|
|
href="Documentation.htm#Conf">shorewall.conf</a>.<br>
|
|
<br>
|
|
</li>
|
|
<li>When an interface name is entered in the SUBNET column of the
|
|
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
|
|
only the first subnet defined on that interface. It did not masquerade
|
|
traffic from:<br>
|
|
<br>
|
|
a) The subnets associated with other addresses on the
|
|
interface.<br>
|
|
b) Subnets accessed through local routers.<br>
|
|
<br>
|
|
Beginning with Shorewall 1.3.14, if you enter an interface name in the
|
|
SUBNET column, shorewall will use the firewall's routing table to
|
|
construct the masquerading/SNAT rules.<br>
|
|
<br>
|
|
Example 1 -- This is how it works in 1.3.14.<br>
|
|
<br>
|
|
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
</pre>
|
|
<pre> [root@gateway test]# shorewall start<br>
|
|
...<br>
|
|
Masqueraded Subnets and Hosts:<br>
|
|
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
|
|
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
|
|
Processing /etc/shorewall/tos...</pre>
|
|
<br>
|
|
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
|
|
connected to an interface that is specified in the SUBNET column of an
|
|
/etc/shorewall/masq entry, your /etc/shorewall/masq file will need
|
|
changing. In most cases, you will simply be able to remove redundant
|
|
entries. In some cases though, you might want to change from using the
|
|
interface name to listing specific subnetworks if the change described
|
|
above will cause masquerading to occur on subnetworks that you don't wish
|
|
to masquerade.<br>
|
|
<br>
|
|
Example 2 -- Suppose that your current config is as follows:<br>
|
|
<br>
|
|
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
eth0 192.168.10.0/24 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
[root@gateway test]#</pre>
|
|
<br>
|
|
In this case, the second entry in /etc/shorewall/masq is no
|
|
longer required.<br>
|
|
<br>
|
|
Example 3 -- What if your current configuration is like this?<br>
|
|
<br>
|
|
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
[root@gateway test]#</pre>
|
|
<br>
|
|
In this case, you would want to change the entry in
|
|
/etc/shorewall/masq to:<br>
|
|
|
|
<pre> #INTERFACE SUBNET ADDRESS<br>
|
|
eth0 192.168.1.0/24 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><br>
|
|
<b>2/5/2003 - Shorewall Support included in Webmin 1.060</b></p>
|
|
|
|
<p>Webmin version 1.060 now has Shorewall support included as standard. See
|
|
<a href="http://www.webmin.com">http://www.webmin.com</a>.<br>
|
|
<b><br>
|
|
2/4/2003 - Shorewall 1.3.14-RC1</b></p>
|
|
|
|
<p>Includes the Beta 2 content plus support for OpenVPN tunnels.</p>
|
|
|
|
<p><b>1/28/2003 - Shorewall 1.3.14-Beta2</b></p>
|
|
|
|
<p>Includes the Beta 1 content plus restores VLAN device names of the form
|
|
$dev.$vid (e.g., eth0.1)</p>
|
|
|
|
<p><b>1/25/2003 - Shorewall 1.3.14-Beta1</b><br>
|
|
</p>
|
|
|
|
<p>The Beta includes the following changes:<br>
|
|
</p>
|
|
<ol>
|
|
<li>An OLD_PING_HANDLING option has been added to shorewall.conf. When set
|
|
to Yes, Shorewall ping handling is as it has always been (see
|
|
http://www.shorewall.net/ping.html).<br>
|
|
<br>
|
|
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
|
|
policies just like any other connection request. The FORWARDPING=Yes
|
|
option in shorewall.conf and the 'noping' and 'filterping' options in
|
|
/etc/shorewall/interfaces will all generate an error.<br>
|
|
<br>
|
|
</li>
|
|
<li>It is now possible to direct Shorewall to create a "label" such
|
|
as "eth0:0" for IP addresses that it creates under
|
|
ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying
|
|
the label instead of just the interface name:<br>
|
|
<br>
|
|
a) In the INTERFACE column of /etc/shorewall/masq<br>
|
|
b) In the INTERFACE column of /etc/shorewall/nat<br>
|
|
</li>
|
|
<li>When an interface name is entered in the SUBNET column of the
|
|
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
|
|
only the first subnet defined on that interface. It did not masquerade
|
|
traffic from:<br>
|
|
<br>
|
|
a) The subnets associated with other addresses on the
|
|
interface.<br>
|
|
b) Subnets accessed through local routers.<br>
|
|
<br>
|
|
Beginning with Shorewall 1.3.14, if you enter an interface name in the
|
|
SUBNET column, shorewall will use the firewall's routing table to
|
|
construct the masquerading/SNAT rules.<br>
|
|
<br>
|
|
Example 1 -- This is how it works in 1.3.14.<br>
|
|
<br>
|
|
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
</pre>
|
|
<pre> [root@gateway test]# shorewall start<br>
|
|
...<br>
|
|
Masqueraded Subnets and Hosts:<br>
|
|
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
|
|
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
|
|
Processing /etc/shorewall/tos...</pre>
|
|
<br>
|
|
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
|
|
connected to an interface that is specified in the SUBNET column of an
|
|
/etc/shorewall/masq entry, your /etc/shorewall/masq file will need
|
|
changing. In most cases, you will simply be able to remove redundant
|
|
entries. In some cases though, you might want to change from using the
|
|
interface name to listing specific subnetworks if the change described
|
|
above will cause masquerading to occur on subnetworks that you don't wish
|
|
to masquerade.<br>
|
|
<br>
|
|
Example 2 -- Suppose that your current config is as follows:<br>
|
|
<br>
|
|
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
eth0 192.168.10.0/24 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
[root@gateway test]#</pre>
|
|
<br>
|
|
In this case, the second entry in /etc/shorewall/masq is no
|
|
longer required.<br>
|
|
<br>
|
|
Example 3 -- What if your current configuration is like this?<br>
|
|
<br>
|
|
|
|
<pre> [root@gateway test]# cat /etc/shorewall/masq<br>
|
|
#INTERFACE SUBNET ADDRESS<br>
|
|
eth0 eth2 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
|
|
<pre> [root@gateway test]# ip route show dev eth2<br>
|
|
192.168.1.0/24 scope link<br>
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254<br>
|
|
[root@gateway test]#</pre>
|
|
<br>
|
|
In this case, you would want to change the entry in
|
|
/etc/shorewall/masq to:<br>
|
|
|
|
<pre> #INTERFACE SUBNET ADDRESS<br>
|
|
eth0 192.168.1.0/24 206.124.146.176<br>
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format</b></p>
|
|
|
|
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13
|
|
documenation. the PDF may be downloaded from</p>
|
|
<a
|
|
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
|
|
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
|
<a
|
|
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a>
|
|
|
|
<p><b>1/17/2003 - shorewall.net has MOVED</b><b> </b></p>
|
|
|
|
<p>Thanks to the generosity of Alex Martin and <a
|
|
href="http://www.rettc.com">Rett Consulting</a>, www.shorewall.net and
|
|
ftp.shorewall.net are now hosted on a system in Bellevue, Washington. A big
|
|
thanks to Alex for making this happen.<br>
|
|
</p>
|
|
|
|
<p><b>1/13/2003 - Shorewall 1.3.13<br>
|
|
</b></p>
|
|
|
|
<p>Just includes a few things that I had on the burner:<br>
|
|
</p>
|
|
<ol>
|
|
<li>A new 'DNAT-' action has been added for entries in the
|
|
/etc/shorewall/rules file. DNAT- is intended for advanced users who wish
|
|
to minimize the number of rules that connection requests must
|
|
traverse.<br>
|
|
<br>
|
|
A Shorewall DNAT rule actually generates two iptables rules: a header
|
|
rewriting rule in the 'nat' table and an ACCEPT rule in the 'filter'
|
|
table. A DNAT- rule only generates the first of these rules. This is
|
|
handy when you have several DNAT rules that would generate the same
|
|
ACCEPT rule.<br>
|
|
<br>
|
|
Here are three rules from my previous rules file:<br>
|
|
<br>
|
|
DNAT net
|
|
dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
|
|
DNAT net
|
|
dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
|
|
ACCEPT net
|
|
dmz:206.124.146.177 tcp www,smtp,ftp,...<br>
|
|
<br>
|
|
These three rules ended up generating _three_ copies of<br>
|
|
<br>
|
|
ACCEPT net
|
|
dmz:206.124.146.177 tcp smtp<br>
|
|
<br>
|
|
By writing the rules this way, I end up with only one copy
|
|
of the ACCEPT rule.<br>
|
|
<br>
|
|
DNAT- net
|
|
dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
|
|
DNAT- net
|
|
dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
|
|
ACCEPT net
|
|
dmz:206.124.146.177 tcp www,smtp,ftp,....<br>
|
|
<br>
|
|
</li>
|
|
<li>The 'shorewall check' command now prints out the applicable policy
|
|
between each pair of zones.<br>
|
|
<br>
|
|
</li>
|
|
<li>A new CLEAR_TC option has been added to shorewall.conf. 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 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/shorewall/tcstart file. That way, your traffic shaping rules can
|
|
still use the 'fwmark' classifier based on packet marking defined in
|
|
/etc/shorewall/tcrules.<br>
|
|
<br>
|
|
</li>
|
|
<li>A new SHARED_DIR variable has been added that allows distribution
|
|
packagers to easily move the shared directory (default
|
|
/usr/lib/shorewall). Users should never have a need to change the value
|
|
of this shorewall.conf setting.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>1/6/2003 - <big><big><big>BURNOUT</big></big></big></b></p>
|
|
|
|
<p><b>Until further notice, I will not be involved in either Shorewall
|
|
Development or Shorewall Support</b></p>
|
|
|
|
<p><b>-Tom Eastep</b><br>
|
|
</p>
|
|
|
|
<p><b>12/30/2002 - Shorewall Documentation in PDF Format</b></p>
|
|
|
|
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12
|
|
documenation. the PDF may be downloaded from</p>
|
|
|
|
<p> <a
|
|
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
|
|
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
|
<a
|
|
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
|
|
</p>
|
|
|
|
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b></p>
|
|
|
|
<p>Features include:<br>
|
|
</p>
|
|
<ol>
|
|
<li>"shorewall refresh" now reloads the traffic shaping rules (tcrules and
|
|
tcstart).</li>
|
|
<li>"shorewall debug [re]start" now turns off debugging after an error
|
|
occurs. This places the point of the failure near the end of the trace
|
|
rather than up in the middle of it.</li>
|
|
<li>"shorewall [re]start" has been speeded up by more than 40% with my
|
|
configuration. Your milage may vary.</li>
|
|
<li>A "shorewall show classifiers" command has been added which shows the
|
|
current packet classification filters. The output from this command is
|
|
also added as a separate page in "shorewall monitor"</li>
|
|
<li>ULOG (must be all caps) is now accepted as a valid syslog level and
|
|
causes the subject packets to be logged using the ULOG target rather than
|
|
the LOG target. This allows you to run ulogd (available from <a
|
|
href="http://www.netfilter.org/projects/ulogd/index.html">http://www.netfilter.org/projects/ulogd/index.html</a>)
|
|
and log all Shorewall messages <a href="shorewall_logging.html">to a
|
|
separate log file</a>.</li>
|
|
<li>If you are running a kernel that has a FORWARD chain in the mangle
|
|
table ("shorewall show mangle" will show you the chains in the mangle
|
|
table), you can set MARK_IN_FORWARD_CHAIN=Yes in <a
|
|
href="Documentation.htm#Conf">shorewall.conf</a>. This allows for marking
|
|
input packets based on their destination even when you are using
|
|
Masquerading or SNAT.</li>
|
|
<li>I have cluttered up the /etc/shorewall directory with empty 'init',
|
|
'start', 'stop' and 'stopped' files. If you already have a file with one
|
|
of these names, don't worry -- the upgrade process won't overwrite your
|
|
file.</li>
|
|
<li>I have added a new RFC1918_LOG_LEVEL variable to <a
|
|
href="Documentation.htm#Conf">shorewall.conf</a>. This variable specifies
|
|
the syslog level at which packets are logged as a result of entries in
|
|
the /etc/shorewall/rfc1918 file. Previously, these packets were always
|
|
logged at the 'info' level.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3<br>
|
|
</b></p>
|
|
This version corrects a problem with Blacklist logging. In Beta 2, if
|
|
BLACKLIST_LOG_LEVEL was set to anything but ULOG, the firewall would fail to
|
|
start and "shorewall refresh" would also fail.<br>
|
|
|
|
|
|
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b></p>
|
|
|
|
<p>The first public Beta version of Shorewall 1.3.12 is now available (Beta 1
|
|
was made available only to a limited audience).<br>
|
|
</p>
|
|
Features include:<br>
|
|
|
|
<ol>
|
|
<li>"shorewall refresh" now reloads the traffic shaping rules (tcrules and
|
|
tcstart).</li>
|
|
<li>"shorewall debug [re]start" now turns off debugging after an error
|
|
occurs. This places the point of the failure near the end of the trace
|
|
rather than up in the middle of it.</li>
|
|
<li>"shorewall [re]start" has been speeded up by more than 40% with my
|
|
configuration. Your milage may vary.</li>
|
|
<li>A "shorewall show classifiers" command has been added which shows the
|
|
current packet classification filters. The output from this command is
|
|
also added as a separate page in "shorewall monitor"</li>
|
|
<li>ULOG (must be all caps) is now accepted as a valid syslog level and
|
|
causes the subject packets to be logged using the ULOG target rather than
|
|
the LOG target. This allows you to run ulogd (available from <a
|
|
href="http://www.netfilter.org/projects/ulogd/index.html">http://www.netfilter.org/projects/ulogd/index.html</a>)
|
|
and log all Shorewall messages <a href="shorewall_logging.html">to a
|
|
separate log file</a>.</li>
|
|
<li>If you are running a kernel that has a FORWARD chain in the mangle
|
|
table ("shorewall show mangle" will show you the chains in the mangle
|
|
table), you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This
|
|
allows for marking input packets based on their destination even when you
|
|
are using Masquerading or SNAT.</li>
|
|
<li>I have cluttered up the /etc/shorewall directory with empty 'init',
|
|
'start', 'stop' and 'stopped' files. If you already have a file with one
|
|
of these names, don't worry -- the upgrade process won't overwrite your
|
|
file.</li>
|
|
</ol>
|
|
You may download the Beta from:<br>
|
|
|
|
|
|
<blockquote>
|
|
<a
|
|
href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
|
|
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
|
|
target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
|
|
</blockquote>
|
|
|
|
<p><b>12/12/2002 - Mandrake Multi Network Firewall <a
|
|
href="http://www.mandrakesoft.com"><img src="images/logo2.png"
|
|
alt="Powered by Mandrake Linux" border="0" height="21" width="140" />
|
|
</a></b></p>
|
|
Shorewall is at the center of MandrakeSoft's recently-announced <a
|
|
href="http://www.mandrakestore.com/mdkinc/index.php?PAGE=tab_0/menu_0.php&id_art=250&LANG_=en#GOTO_250">Multi
|
|
Network Firewall (MNF)</a> product. Here is the <a
|
|
href="http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">press
|
|
release</a>.<br>
|
|
|
|
|
|
<p><b>12/7/2002 - Shorewall Support for Mandrake 9.0</b></p>
|
|
|
|
<p>Two months and 3 days after I ordered Mandrake 9.0, it was finally
|
|
delivered. I have installed 9.0 on one of my systems and I am now in a
|
|
position to support Shorewall users who run Mandrake 9.0.</p>
|
|
|
|
<p><b>12/6/2002 - Debian 1.3.11a Packages Available<br>
|
|
</b></p>
|
|
|
|
<p>Apt-get sources listed at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
|
|
|
|
<p><b>12/3/2002 - Shorewall 1.3.11a</b></p>
|
|
|
|
<p>This is a bug-fix roll up which includes Roger Aich's fix for DNAT with
|
|
excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 users who don't
|
|
need rules of this type need not upgrade to 1.3.11.</p>
|
|
|
|
<p><b>11/24/2002 - Shorewall 1.3.11</b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>A 'tcpflags' option has been added to entries in <a
|
|
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>. This
|
|
option causes Shorewall to make a set of sanity check on TCP packet
|
|
header flags.</li>
|
|
<li>It is now allowed to use 'all' in the SOURCE or DEST column in a <a
|
|
href="Documentation.htm#Rules">rule</a>. When used, 'all' must appear by
|
|
itself (in may not be qualified) and it does not enable intra-zone
|
|
traffic. For example, the rule<br>
|
|
<br>
|
|
ACCEPT loc all tcp 80<br>
|
|
<br>
|
|
does not enable http traffic from 'loc' to 'loc'.</li>
|
|
<li>Shorewall's use of the 'echo' command is now compatible with bash
|
|
clones such as ash and dash.</li>
|
|
<li>fw->fw policies now generate a startup error. fw->fw rules
|
|
generate a warning and are ignored</li>
|
|
</ul>
|
|
|
|
<p><b>11/14/2002 - Shorewall Documentation in PDF Format</b></p>
|
|
|
|
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10
|
|
documenation. the PDF may be downloaded from</p>
|
|
|
|
<p> <a
|
|
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
|
|
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
|
|
<a
|
|
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
|
|
</p>
|
|
|
|
<p><b>11/09/2002 - Shorewall is Back at SourceForge</b></p>
|
|
|
|
<p>The main Shorewall 1.3 web site is now back at SourceForge at <a
|
|
href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net</a>.<br>
|
|
</p>
|
|
|
|
<p><b>11/09/2002 - Shorewall 1.3.10</b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>You may now <a href="IPSEC.htm#Dynamic">define the contents of a zone
|
|
dynamically</a> with the <a
|
|
href="starting_and_stopping_shorewall.htm">"shorewall add" and "shorewall
|
|
delete" commands</a>. These commands are expected to be used primarily
|
|
within <a href="http://www.xs4all.nl/%7Efreeswan/">FreeS/Wan</a> updown
|
|
scripts.</li>
|
|
<li>Shorewall can now do <a href="MAC_Validation.html">MAC verification</a>
|
|
on ethernet segments. You can specify the set of allowed MAC addresses on
|
|
the segment and you can optionally tie each MAC address to one or more IP
|
|
addresses.</li>
|
|
<li>PPTP Servers and Clients running on the firewall system may now be
|
|
defined in the <a href="PPTP.htm">/etc/shorewall/tunnels</a> file.</li>
|
|
<li>A new 'ipsecnat' tunnel type is supported for use when the <a
|
|
href="IPSEC.htm">remote IPSEC endpoint is behind a NAT gateway</a>.</li>
|
|
<li>The PATH used by Shorewall may now be specified in <a
|
|
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
|
|
<li>The main firewall script is now /usr/lib/shorewall/firewall. The script
|
|
in /etc/init.d/shorewall is very small and uses /sbin/shorewall to do the
|
|
real work. This change makes custom distributions such as for Debian and
|
|
for Gentoo easier to manage since it is /etc/init.d/shorewall that tends
|
|
to have distribution-dependent code</li>
|
|
</ul>
|
|
|
|
<p><b>10/24/2002 - Shorewall is now in Gentoo Linux</b> <a
|
|
href="http://www.gentoo.org"><br>
|
|
</a></p>
|
|
Alexandru Hartmann reports that his Shorewall package is now a part of <a
|
|
href="http://www.gentoo.org">the Gentoo Linux distribution</a>. Thanks
|
|
Alex!<br>
|
|
|
|
|
|
<p><b>10/23/2002 - Shorewall 1.3.10 Beta 1</b></p>
|
|
In this version:<br>
|
|
|
|
<ul>
|
|
<li>You may now <a href="IPSEC.htm#Dynamic">define the contents of a zone
|
|
dynamically</a> with the <a
|
|
href="starting_and_stopping_shorewall.htm">"shorewall add" and "shorewall
|
|
delete" commands</a>. These commands are expected to be used primarily
|
|
within <a href="http://www.xs4all.nl/%7Efreeswan/">FreeS/Wan</a> updown
|
|
scripts.</li>
|
|
<li>Shorewall can now do <a href="MAC_Validation.html">MAC verification</a>
|
|
on ethernet segments. You can specify the set of allowed MAC addresses on
|
|
the segment and you can optionally tie each MAC address to one or more IP
|
|
addresses.</li>
|
|
<li>PPTP Servers and Clients running on the firewall system may now be
|
|
defined in the <a href="PPTP.htm">/etc/shorewall/tunnels</a> file.</li>
|
|
<li>A new 'ipsecnat' tunnel type is supported for use when the <a
|
|
href="IPSEC.htm">remote IPSEC endpoint is behind a NAT gateway</a>.</li>
|
|
<li>The PATH used by Shorewall may now be specified in <a
|
|
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
|
|
<li>The main firewall script is now /usr/lib/shorewall/firewall. The script
|
|
in /etc/init.d/shorewall is very small and uses /sbin/shorewall to do the
|
|
real work. This change makes custom distributions such as for Debian and
|
|
for Gentoo easier to manage since it is /etc/init.d/shorewall that tends
|
|
to have distribution-dependent code.</li>
|
|
</ul>
|
|
You may download the Beta from:<br>
|
|
|
|
<ul>
|
|
<li><a
|
|
href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a></li>
|
|
<li><a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
|
|
target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a></li>
|
|
</ul>
|
|
|
|
<p><b>10/10/2002 - Debian 1.3.9b Packages Available<br>
|
|
</b></p>
|
|
|
|
<p>Apt-get sources listed at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
|
|
|
|
<p><b>10/9/2002 - Shorewall 1.3.9b</b></p>
|
|
This release rolls up fixes to the installer and to the firewall script.<br>
|
|
|
|
|
|
<p><b>10/6/2002 - Shorewall.net now running on RH8.0<br>
|
|
</b><br>
|
|
The firewall and server here at shorewall.net are now running RedHat release
|
|
8.0.<br>
|
|
<b><br>
|
|
9/30/2002 - Shorewall 1.3.9a</b></p>
|
|
Roles up the fix for broken tunnels.<br>
|
|
|
|
|
|
<p><b>9/30/2002 - TUNNELS Broken in 1.3.9!!!</b></p>
|
|
There is an updated firewall script at <a
|
|
href="ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall"
|
|
target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall</a>
|
|
-- copy that file to /usr/lib/shorewall/firewall.<br>
|
|
|
|
|
|
<p><b>9/28/2002 - Shorewall 1.3.9</b></p>
|
|
|
|
<p>In this version:<br>
|
|
</p>
|
|
<ul>
|
|
<li><a href="configuration_file_basics.htm#dnsnames">DNS Names</a> are now
|
|
allowed in Shorewall config files (although I recommend against using
|
|
them).</li>
|
|
<li>The connection SOURCE may now be qualified by both interface and IP
|
|
address in a <a href="Documentation.htm#Rules">Shorewall rule</a>.</li>
|
|
<li>Shorewall startup is now disabled after initial installation until the
|
|
file /etc/shorewall/startup_disabled is removed. This avoids nasty
|
|
surprises during reboot for users who install Shorewall but don't
|
|
configure it.</li>
|
|
<li>The 'functions' and 'version' files and the 'firewall' symbolic link
|
|
have been moved from /var/lib/shorewall to /usr/lib/shorewall to appease
|
|
the LFS police at Debian.<br>
|
|
</li>
|
|
</ul>
|
|
|
|
<p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
|
|
Restored</b><br>
|
|
</p>
|
|
<img src="images/j0233056.gif" alt="Brown Paper Bag" align="left" height="86"
|
|
width="50" /> A couple of recent configuration changes at www.shorewall.net
|
|
broke the Search facility:<br>
|
|
|
|
|
|
<blockquote>
|
|
<ol>
|
|
<li>Mailing List Archive Search was not available.</li>
|
|
<li>The Site Search index was incomplete</li>
|
|
<li>Only one page of matches was presented.</li>
|
|
</ol>
|
|
</blockquote>
|
|
Hopefully these problems are now corrected.
|
|
|
|
<p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
|
|
Restored<br>
|
|
</b></p>
|
|
A couple of recent configuration changes at www.shorewall.net had the
|
|
negative effect of breaking the Search facility:<br>
|
|
|
|
<ol>
|
|
<li>Mailing List Archive Search was not available.</li>
|
|
<li>The Site Search index was incomplete</li>
|
|
<li>Only one page of matches was presented.</li>
|
|
</ol>
|
|
Hopefully these problems are now corrected.<br>
|
|
|
|
|
|
<p><b>9/18/2002 - Debian 1.3.8 Packages Available<br>
|
|
</b></p>
|
|
|
|
<p>Apt-get sources listed at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
|
|
|
|
<p><b>9/16/2002 - Shorewall 1.3.8</b></p>
|
|
|
|
<p>In this version:<br>
|
|
</p>
|
|
<ul>
|
|
<li>A <a href="Documentation.htm#Conf">NEWNOTSYN</a> option has been added
|
|
to shorewall.conf. This option determines whether Shorewall accepts TCP
|
|
packets which are not part of an established connection and that are not
|
|
'SYN' packets (SYN flag on and ACK flag off).</li>
|
|
<li>The need for the 'multi' option to communicate between zones za and zb
|
|
on the same interface is removed in the case where the chain 'za2zb'
|
|
and/or 'zb2za' exists. 'za2zb' will exist if:</li>
|
|
<li
|
|
style="list-style-type: none; list-style-position: outside; list-style-image: none;"><ul>
|
|
<li>There is a policy for za to zb; or</li>
|
|
<li>There is at least one rule for za to zb.</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
<ul>
|
|
<li>The /etc/shorewall/blacklist file now contains three columns. In
|
|
addition to the SUBNET/ADDRESS column, there are optional PROTOCOL and
|
|
PORT columns to block only certain applications from the blacklisted
|
|
addresses.<br>
|
|
</li>
|
|
</ul>
|
|
|
|
<p><b>9/11/2002 - Debian 1.3.7c Packages Available</b></p>
|
|
|
|
<p>Apt-get sources listed at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
<p><b>9/2/2002 - Shorewall 1.3.7c</b></p>
|
|
|
|
<p>This is a role up of a fix for "DNAT" rules where the source zone is $FW
|
|
(fw).</p>
|
|
|
|
<p><b>8/31/2002 - I'm not available</b></p>
|
|
|
|
<p>I'm currently on vacation -- please respect my need for a couple of
|
|
weeks free of Shorewall problem reports.</p>
|
|
|
|
<p>-Tom</p>
|
|
|
|
<p><b>8/26/2002 - Shorewall 1.3.7b</b></p>
|
|
|
|
<p>This is a role up of the "shorewall refresh" bug fix and the change which
|
|
reverses the order of "dhcp" and "norfc1918" checking.</p>
|
|
|
|
<p><b>8/26/2002 - French FTP Mirror is Operational</b></p>
|
|
|
|
<p><a target="_blank"
|
|
href="ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall</a>
|
|
is now available.</p>
|
|
|
|
<p><b>8/25/2002 - Shorewall Mirror in France</b></p>
|
|
|
|
<p>Thanks to a Shorewall user in Paris, the Shorewall web site is now
|
|
mirrored at <a target="_top"
|
|
href="http://france.shorewall.net">http://france.shorewall.net</a>.</p>
|
|
|
|
<p><b>8/25/2002 - Shorewall 1.3.7a Debian Packages Available</b></p>
|
|
|
|
<p>Lorenzo Martignoni reports that the packages for version 1.3.7a are
|
|
available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
<p><b>8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author
|
|
-- Shorewall 1.3.7a released<img src="images/j0233056.gif"
|
|
alt="Brown Paper Bag Graphic" align="middle" border="0" height="80"
|
|
width="50" /></b></p>
|
|
|
|
<p>1.3.7a corrects problems occurring in rules file processing when starting
|
|
Shorewall 1.3.7.</p>
|
|
|
|
<p><b>8/22/2002 - Shorewall 1.3.7 Released 8/13/2002</b></p>
|
|
|
|
<p>Features in this release include:</p>
|
|
<ul>
|
|
<li>The 'icmp.def' file is now empty! The rules in that file were required
|
|
in ipchains firewalls but are not required in Shorewall. Users who have
|
|
ALLOWRELATED=No in <a href="Documentation.htm#Conf">shorewall.conf</a>
|
|
should see the <a href="errata.htm#Upgrade">Upgrade Issues</a>.</li>
|
|
<li>A 'FORWARDPING' option has been added to <a
|
|
href="Documentation.htm#Conf">shorewall.conf</a>. The effect of setting
|
|
this variable to Yes is the same as the effect of adding an ACCEPT rule
|
|
for ICMP echo-request in <a
|
|
href="shorewall_extension_scripts.htm">/etc/shorewall/icmpdef</a>. Users
|
|
who have such a rule in icmpdef are encouraged to switch to
|
|
FORWARDPING=Yes.</li>
|
|
<li>The loopback CLASS A Network (127.0.0.0/8) has been added to the
|
|
rfc1918 file.</li>
|
|
<li>Shorewall now works with iptables 1.2.7</li>
|
|
<li>The documentation and web site no longer uses FrontPage themes.</li>
|
|
</ul>
|
|
|
|
<p>I would like to thank John Distler for his valuable input regarding TCP
|
|
SYN and ICMP treatment in Shorewall. That input has led to marked improvement
|
|
in Shorewall in the last two releases.</p>
|
|
|
|
<p><b>8/13/2002 - Documentation in the <a target="_top"
|
|
href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS
|
|
Repository</a></b></p>
|
|
|
|
<p>The Shorewall-docs project now contains just the HTML and image files -
|
|
the Frontpage files have been removed.</p>
|
|
|
|
<p><b>8/7/2002 - <i>STABLE</i></b> <b>branch added to <a target="_top"
|
|
href="http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS
|
|
Repository</a></b></p>
|
|
|
|
<p>This branch will only be updated after I release a new version of
|
|
Shorewall so you can always update from this branch to get the latest stable
|
|
tree.</p>
|
|
|
|
<p><b>8/7/2002 - <a href="errata.htm#Upgrade">Upgrade Issues</a> section
|
|
added to the <a href="errata.htm">Errata Page</a></b></p>
|
|
|
|
<p>Now there is one place to go to look for issues involved with upgrading to
|
|
recent versions of Shorewall.</p>
|
|
|
|
<p><b>8/7/2002 - Shorewall 1.3.6</b></p>
|
|
|
|
<p>This is primarily a bug-fix rollup with a couple of new features:</p>
|
|
<ul>
|
|
<li>The latest <a href="shorewall_quickstart_guide.htm">QuickStart
|
|
Guides</a> including the <a href="shorewall_setup_guide.htm">Shorewall
|
|
Setup Guide.</a></li>
|
|
<li>Shorewall will now DROP TCP packets that are not part of or related to
|
|
an existing connection and that are not SYN packets. These "New not SYN"
|
|
packets may be optionally logged by setting the LOGNEWNOTSYN option in <a
|
|
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
|
|
<li>The processing of "New not SYN" packets may be extended by commands in
|
|
the new <a href="shorewall_extension_scripts.htm">newnotsyn extension
|
|
script</a>.</li>
|
|
</ul>
|
|
|
|
<p><b>7/30/2002 - Shorewall 1.3.5b Released</b></p>
|
|
|
|
<p>This interim release:</p>
|
|
<ul>
|
|
<li>Causes the firewall script to remove the lock file if it is killed.</li>
|
|
<li>Once again allows lists in the second column of the <a
|
|
href="Documentation.htm#Hosts">/etc/shorewall/hosts</a> file.</li>
|
|
<li>Includes the latest <a href="shorewall_quickstart_guide.htm">QuickStart
|
|
Guides</a>.</li>
|
|
</ul>
|
|
|
|
<p><b>7/29/2002 - New Shorewall Setup Guide Available</b></p>
|
|
|
|
<p>The first draft of this guide is available at <a
|
|
href="http://www.shorewall.net/shorewall_setup_guide.htm">http://www.shorewall.net/shorewall_setup_guide.htm</a>.
|
|
The guide is intended for use by people who are setting up Shorewall to
|
|
manage multiple public IP addresses and by people who want to learn more
|
|
about Shorewall than is described in the single-address guides. Feedback on
|
|
the new guide is welcome.</p>
|
|
|
|
<p><b>7/28/2002 - Shorewall 1.3.5 Debian Package Available</b></p>
|
|
|
|
<p>Lorenzo Martignoni reports that the packages are version 1.3.5a and are
|
|
available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
<p><b>7/27/2002 - Shorewall 1.3.5a Released</b></p>
|
|
|
|
<p>This interim release restores correct handling of REDIRECT rules.</p>
|
|
|
|
<p><b>7/26/2002 - Shorewall 1.3.5 Released</b></p>
|
|
|
|
<p>This will be the last Shorewall release for a while. I'm going to be
|
|
focusing on rewriting a lot of the documentation.</p>
|
|
|
|
<p><b> </b> In this version:</p>
|
|
<ul>
|
|
<li>Empty and invalid source and destination qualifiers are now detected in
|
|
the rules file. It is a good idea to use the 'shorewall check' command
|
|
before you issue a 'shorewall restart' command be be sure that you don't
|
|
have any configuration problems that will prevent a successful
|
|
restart.</li>
|
|
<li>Added <b>MERGE_HOSTS</b> variable in <a
|
|
href="Documentation.htm#Conf">shorewall.conf</a> to provide saner
|
|
behavior of the /etc/shorewall/hosts file.</li>
|
|
<li>The time that the counters were last reset is now displayed in the
|
|
heading of the 'status' and 'show' commands.</li>
|
|
<li>A <b>proxyarp</b> option has been added for entries in <a
|
|
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>. This
|
|
option facilitates Proxy ARP sub-netting as described in the Proxy ARP
|
|
subnetting mini-HOWTO (<a
|
|
href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>).
|
|
Specifying the proxyarp option for an interface causes Shorewall to set
|
|
/proc/sys/net/ipv4/conf/<interface>/proxy_arp.</li>
|
|
<li>The Samples have been updated to reflect the new capabilities in this
|
|
release.</li>
|
|
</ul>
|
|
|
|
<p><b>7/16/2002 - New Mirror in Argentina</b></p>
|
|
|
|
<p>Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in
|
|
Argentina. Thanks Buanzo!!!</p>
|
|
|
|
<p><b>7/16/2002 - Shorewall 1.3.4 Released</b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>A new <a
|
|
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>
|
|
file has been added. This file is intended to eventually replace the
|
|
<b>routestopped</b> option in the /etc/shorewall/interface and
|
|
/etc/shorewall/hosts files. This new file makes remote firewall
|
|
administration easier by allowing any IP or subnet to be enabled while
|
|
Shorewall is stopped.</li>
|
|
<li>An /etc/shorewall/stopped <a href="Documentation.htm#Scripts">extension
|
|
script</a> has been added. This script is invoked after Shorewall has
|
|
stopped.</li>
|
|
<li>A <b>DETECT_DNAT_ADDRS</b> option has been added to <a
|
|
href="Documentation.htm#Conf">/etc/shoreall/shorewall.conf</a>. When this
|
|
option is selected, DNAT rules only apply when the destination address is
|
|
the external interface's primary IP address.</li>
|
|
<li>The <a href="shorewall_quickstart_guide.htm">QuickStart Guide</a> has
|
|
been broken into three guides and has been almost entirely rewritten.</li>
|
|
<li>The Samples have been updated to reflect the new capabilities in this
|
|
release.</li>
|
|
</ul>
|
|
|
|
<p><b>7/8/2002 - Shorewall 1.3.3 Debian Package Available</b></p>
|
|
|
|
<p>Lorenzo Marignoni reports that the packages are available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
<p><b>7/6/2002 - Shorewall 1.3.3 Released</b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>Entries in /etc/shorewall/interface that use the wildcard character
|
|
("+") now have the "multi" option assumed.</li>
|
|
<li>The 'rfc1918' chain in the mangle table has been renamed 'man1918' to
|
|
make log messages generated from that chain distinguishable from those
|
|
generated by the 'rfc1918' chain in the filter table.</li>
|
|
<li>Interface names appearing in the hosts file are now validated against
|
|
the interfaces file.</li>
|
|
<li>The TARGET column in the rfc1918 file is now checked for
|
|
correctness.</li>
|
|
<li>The chain structure in the nat table has been changed to reduce the
|
|
number of rules that a packet must traverse and to correct problems with
|
|
NAT_BEFORE_RULES=No</li>
|
|
<li>The "hits" command has been enhanced.</li>
|
|
</ul>
|
|
|
|
<p><b>6/25/2002 - Samples Updated for 1.3.2</b></p>
|
|
|
|
<p>The comments in the sample configuration files have been updated to
|
|
reflect new features introduced in Shorewall 1.3.2.</p>
|
|
|
|
<p><b>6/25/2002 - Shorewall 1.3.1 Debian Package Available</b></p>
|
|
|
|
<p>Lorenzo Marignoni reports that the package is available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
<p><b>6/19/2002 - Documentation Available in PDF Format</b></p>
|
|
|
|
<p>Thanks to Mike Martinez, the Shorewall Documentation is now available for
|
|
<a href="download.htm">download</a> in <a
|
|
href="http://www.adobe.com">Adobe</a> PDF format.</p>
|
|
|
|
<p><b>6/16/2002 - Shorewall 1.3.2 Released</b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>A <a href="Documentation.htm#Starting">logwatch command</a> has been
|
|
added to /sbin/shorewall.</li>
|
|
<li>A <a href="blacklisting_support.htm">dynamic blacklist facility</a> has
|
|
been added.</li>
|
|
<li>Support for the <a href="Documentation.htm#Conf">Netfilter multiport
|
|
match function</a> has been added.</li>
|
|
<li>The files <b>firewall, functions</b> and <b>version</b> have been moved
|
|
from /etc/shorewall to /var/lib/shorewall.</li>
|
|
</ul>
|
|
|
|
<p><b>6/6/2002 - Why CVS Web access is Password Protected</b></p>
|
|
|
|
<p>Last weekend, I installed the CVS Web package to provide brower-based
|
|
access to the Shorewall CVS repository. Since then, I have had several
|
|
instances where my server was almost unusable due to the high load generated
|
|
by website copying tools like HTTrack and WebStripper. These mindless
|
|
tools:</p>
|
|
<ul>
|
|
<li>Ignore robot.txt files.</li>
|
|
<li>Recursively copy everything that they find.</li>
|
|
<li>Should be classified as weapons rather than tools.</li>
|
|
</ul>
|
|
|
|
<p>These tools/weapons are particularly damaging when combined with CVS Web
|
|
because they doggedly follow every link in the cgi-generated HTML resulting
|
|
in 1000s of executions of the cvsweb.cgi script. Yesterday, I spend several
|
|
hours implementing measures to block these tools but unfortunately, these
|
|
measures resulted in my server OOM-ing under even moderate load.</p>
|
|
|
|
<p>Until I have the time to understand the cause of the OOM (or until I buy
|
|
more RAM if that is what is required), CVS Web access will remain Password
|
|
Protected.</p>
|
|
|
|
<p><b>6/5/2002 - Shorewall 1.3.1 Debian Package Available</b></p>
|
|
|
|
<p>Lorenzo Marignoni reports that the package is available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>
|
|
|
|
<p><b>6/2/2002 - Samples Corrected</b></p>
|
|
|
|
<p>The 1.3.0 samples configurations had several serious problems that
|
|
prevented DNS and SSH from working properly. These problems have been
|
|
corrected in the <a href="/pub/shorewall/samples-1.3.1">1.3.1 samples.</a></p>
|
|
|
|
<p><b>6/1/2002 - Shorewall 1.3.1 Released</b></p>
|
|
|
|
<p>Hot on the heels of 1.3.0, this release:</p>
|
|
<ul>
|
|
<li>Corrects a serious problem with "all <i><zone></i> CONTINUE"
|
|
policies. This problem is present in all versions of Shorewall that
|
|
support the CONTINUE policy. These previous versions optimized away the
|
|
"all2<i><zone></i>" chain and replaced it with the "all2all" chain
|
|
with the usual result that a policy of REJECT was enforced rather than
|
|
the intended CONTINUE policy.</li>
|
|
<li>Adds an <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</a>
|
|
file for defining the exact behavior of the <a
|
|
href="Documentation.htm#Interfaces">'norfc1918' interface option</a>.</li>
|
|
</ul>
|
|
|
|
<p><b>5/29/2002 - Shorewall 1.3.0 Released</b></p>
|
|
|
|
<p>In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0
|
|
includes:</p>
|
|
<ul>
|
|
<li>A 'filterping' interface option that allows ICMP echo-request (ping)
|
|
requests addressed to the firewall to be handled by entries in
|
|
/etc/shorewall/rules and /etc/shorewall/policy.</li>
|
|
</ul>
|
|
|
|
<p><b>5/23/2002 - Shorewall 1.3 RC1 Available</b></p>
|
|
|
|
<p>In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92)
|
|
incorporates the following:</p>
|
|
<ul>
|
|
<li>Support for the /etc/shorewall/whitelist file has been withdrawn. If
|
|
you need whitelisting, see <a
|
|
href="/1.3/whitelisting_under_shorewall.htm">these instructions</a>.</li>
|
|
</ul>
|
|
|
|
<p><b>5/19/2002 - Shorewall 1.3 Beta 2 Available</b></p>
|
|
|
|
<p>In addition to the changes in Beta 1, this release which carries the
|
|
designation 1.2.91 adds:</p>
|
|
<ul>
|
|
<li>The structure of the firewall is changed markedly. There is now an
|
|
INPUT and a FORWARD chain for each interface; this reduces the number of
|
|
rules that a packet must traverse, especially in complicated setups.</li>
|
|
<li><a href="Documentation.htm#Exclude">Sub-zones may now be excluded from
|
|
DNAT and REDIRECT rules.</a></li>
|
|
<li>The names of the columns in a number of the configuration files have
|
|
been changed to be more consistent and self-explanatory and the
|
|
documentation has been updated accordingly.</li>
|
|
<li>The sample configurations have been updated for 1.3.</li>
|
|
</ul>
|
|
|
|
<p><b>5/17/2002 - Shorewall 1.3 Beta 1 Available</b></p>
|
|
|
|
<p>Beta 1 carries the version designation 1.2.90 and implements the following
|
|
features:</p>
|
|
<ul>
|
|
<li>Simplified rule syntax which makes the intent of each rule clearer and
|
|
hopefully makes Shorewall easier to learn.</li>
|
|
<li>Upward compatibility with 1.2 configuration files has been maintained
|
|
so that current users can migrate to the new syntax at their
|
|
convenience.</li>
|
|
<li><b><font color="#CC6666">WARNING: Compatibility with the old
|
|
parameterized sample configurations has NOT been maintained. Users still
|
|
running those configurations should migrate to the new sample
|
|
configurations before upgrading to 1.3 Beta 1.</font></b></li>
|
|
</ul>
|
|
|
|
<p><b>5/4/2002 - Shorewall 1.2.13 is Available</b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li><a href="Documentation.htm#Whitelist">White-listing</a> is
|
|
supported.</li>
|
|
<li><a href="Documentation.htm#Policy">SYN-flood protection</a> is
|
|
added.</li>
|
|
<li>IP addresses added under <a
|
|
href="Documentation.htm#Conf">ADD_IP_ALIASES and ADD_SNAT_ALIASES</a> now
|
|
inherit the VLSM and Broadcast Address of the interface's primary IP
|
|
address.</li>
|
|
<li>The order in which port forwarding DNAT and Static DNAT <a
|
|
href="Documentation.htm#Conf">can now be reversed</a> so that port
|
|
forwarding rules can override the contents of <a
|
|
href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</li>
|
|
</ul>
|
|
|
|
<p><b>4/30/2002 - Shorewall Debian News</b></p>
|
|
|
|
<p>Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the <a
|
|
href="http://packages.debian.org/testing/net/shorewall.html">Debian Testing
|
|
Branch</a> and the <a
|
|
href="http://packages.debian.org/unstable/net/shorewall.html">Debian Unstable
|
|
Branch</a>.</p>
|
|
|
|
<p><b>4/20/2002 - Shorewall 1.2.12 is Available</b></p>
|
|
<ul>
|
|
<li>The 'try' command works again</li>
|
|
<li>There is now a single RPM that also works with SUSE.</li>
|
|
</ul>
|
|
|
|
<p><b>4/17/2002 - Shorewall Debian News</b></p>
|
|
|
|
<p>Lorenzo Marignoni reports that:</p>
|
|
<ul>
|
|
<li>Shorewall 1.2.10 is in the <a
|
|
href="http://packages.debian.org/testing/net/shorewall.html">Debian
|
|
Testing Branch</a></li>
|
|
<li>Shorewall 1.2.11 is in the <a
|
|
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
|
|
Unstable Branch</a></li>
|
|
</ul>
|
|
|
|
<p>Thanks, Lorenzo!</p>
|
|
|
|
<p><b>4/16/2002 - Shorewall 1.2.11 RPM Available for SUSE</b></p>
|
|
|
|
<p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan Mohr</a>, there
|
|
is now a Shorewall 1.2.11 <a
|
|
href="http://www.shorewall.net/pub/shorewall/shorewall-1.2-11.i686.suse73.rpm">SUSE
|
|
RPM</a> available.</p>
|
|
|
|
<p><b>4/13/2002 - Shorewall 1.2.11 Available</b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>The 'try' command now accepts an optional timeout. If the timeout is
|
|
given in the command, the standard configuration will automatically be
|
|
restarted after the new configuration has been running for that length of
|
|
time. This prevents a remote admin from being locked out of the firewall
|
|
in the case where the new configuration starts but prevents access.</li>
|
|
<li>Kernel route filtering may now be enabled globally using the new
|
|
ROUTE_FILTER parameter in <a
|
|
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
|
|
<li>Individual IP source addresses and/or subnets may now be excluded from
|
|
masquerading/SNAT.</li>
|
|
<li>Simple "Yes/No" and "On/Off" values are now case-insensitive in
|
|
/etc/shorewall/shorewall.conf.</li>
|
|
</ul>
|
|
|
|
<p><b>4/13/2002 - Hamburg Mirror now has FTP</b></p>
|
|
|
|
<p>Stefan now has an FTP mirror at <a target="_blank"
|
|
href="ftp://germany.shorewall.net/pub/shorewall">ftp://germany.shorewall.net/pub/shorewall</a>.
|
|
Thanks Stefan!</p>
|
|
|
|
<p><b>4/12/2002 - New Mirror in Hamburg</b></p>
|
|
|
|
<p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan Mohr</a>, there
|
|
is now a mirror of the Shorewall website at <a target="_top"
|
|
href="http://germany.shorewall.net">http://germany.shorewall.net</a>.</p>
|
|
|
|
<p><b>4/10/2002 - Shorewall QuickStart Guide Version 1.1 Available</b></p>
|
|
|
|
<p><a href="shorewall_quickstart_guide.htm">Version 1.1 of the QuickStart
|
|
Guide</a> is now available. Thanks to those who have read version 1.0 and
|
|
offered their suggestions. Corrections have also been made to the sample
|
|
scripts.</p>
|
|
|
|
<p><b>4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available</b></p>
|
|
|
|
<p><a href="shorewall_quickstart_guide.htm">Version 1.0 of the QuickStart
|
|
Guide</a> is now available. This Guide and its accompanying sample
|
|
configurations are expected to provide a replacement for the recently
|
|
withdrawn parameterized samples.</p>
|
|
|
|
<p><b>4/8/2002 - Parameterized Samples Withdrawn</b></p>
|
|
|
|
<p>Although the <a
|
|
href="http://www.shorewall.net/pub/shorewall/samples-1.2.1/">parameterized
|
|
samples</a> have allowed people to get a firewall up and running quickly,
|
|
they have unfortunately set the wrong level of expectation among those who
|
|
have used them. I am therefore withdrawing support for the samples and I am
|
|
recommending that they not be used in new Shorewall installations.</p>
|
|
|
|
<p><b>4/2/2002 - Updated Log Parser</b></p>
|
|
|
|
<p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has provided an
|
|
updated version of his <a href="pub/shorewall/parsefw/">CGI-based log
|
|
parser</a> with corrected date handling.</p>
|
|
|
|
<p><b>3/30/2002 - Shorewall Website Search Improvements</b></p>
|
|
|
|
<p>The quick search on the home page now excludes the mailing list archives.
|
|
The <a href="htdig/search.html">Extended Search</a> allows excluding the
|
|
archives or restricting the search to just the archives. An archive search
|
|
form is also available on the <a
|
|
href="http://lists.shorewall.net/mailing_list.htm">mailing list information
|
|
page</a>.</p>
|
|
|
|
<p><b>3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni)</b></p>
|
|
<ul>
|
|
<li>The 1.2.10 Debian Package is available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</li>
|
|
<li>Shorewall 1.2.9 is now in the <a
|
|
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
|
|
Unstable Distribution</a>.</li>
|
|
</ul>
|
|
|
|
<p><b>3/25/2002 - Log Parser Available</b></p>
|
|
|
|
<p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has provided a <a
|
|
href="pub/shorewall/parsefw/">CGI-based log parser</a> for Shorewall. Thanks
|
|
John.</p>
|
|
|
|
<p><b>3/20/2002 - Shorewall 1.2.10 Released</b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>A "shorewall try" command has been added (syntax: shorewall try
|
|
<i><configuration directory></i>). This command attempts "shorewall
|
|
-c <i><configuration directory></i> start" and if that results in
|
|
the firewall being stopped due to an error, a "shorewall start" command
|
|
is executed. The 'try' command allows you to create a new <a
|
|
href="Documentation.htm#Configs">configuration</a> and attempt to start
|
|
it; if there is an error that leaves your firewall in the stopped state,
|
|
it will automatically be restarted using the default configuration (in
|
|
/etc/shorewall).</li>
|
|
<li>A new variable ADD_SNAT_ALIASES has been added to <a
|
|
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>. If this
|
|
variable is set to "Yes", Shorewall will automatically add IP addresses
|
|
listed in the third column of the <a
|
|
href="Documentation.htm#Masq">/etc/shorewall/masq</a> file.</li>
|
|
<li>Copyright notices have been added to the documenation.</li>
|
|
</ul>
|
|
|
|
<p><b>3/11/2002 - Shorewall 1.2.9 Released</b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>Filtering by <a href="Documentation.htm#MAC">MAC address</a> has been
|
|
added. MAC addresses may be used as the source address in:
|
|
<ul>
|
|
<li>Filtering rules (<a
|
|
href="Documentation.htm#Rules">/etc/shorewall/rules</a>)</li>
|
|
<li>Traffic Control Classification Rules (<a
|
|
href="traffic_shaping.htm#tcrules">/etc/shorewall/tcrules</a>)</li>
|
|
<li>TOS Rules (<a
|
|
href="Documentation.htm#TOS">/etc/shorewall/tos</a>)</li>
|
|
<li>Blacklist (<a
|
|
href="Documentation.htm#Blacklist">/etc/shorewall/blacklist</a>)</li>
|
|
</ul>
|
|
</li>
|
|
<li>Several bugs have been fixed</li>
|
|
<li>The 1.2.9 Debian Package is also available at <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</li>
|
|
</ul>
|
|
|
|
<p><b>3/1/2002 - 1.2.8 Debian Package is Available</b></p>
|
|
|
|
<p>See <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
|
|
<p><b>2/25/2002 - New Two-interface Sample</b></p>
|
|
|
|
<p>I've enhanced the two interface sample to allow access from the firewall
|
|
to servers in the local zone - <a
|
|
href="http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz">http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz</a></p>
|
|
|
|
<p><b>2/23/2002 - Shorewall 1.2.8 Released</b></p>
|
|
|
|
<p>Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects
|
|
problems associated with the lock file used to prevent multiple
|
|
state-changing operations from occuring simultaneously. My apologies for any
|
|
inconvenience my carelessness may have caused.</p>
|
|
|
|
<p><b>2/22/2002 - Shorewall 1.2.7 Released</b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>UPnP probes (UDP destination port 1900) are now silently dropped in the
|
|
<i>common</i> chain</li>
|
|
<li>RFC 1918 checking in the mangle table has been streamlined to no longer
|
|
require packet marking. RFC 1918 checking in the filter table has been
|
|
changed to require half as many rules as previously.</li>
|
|
<li>A 'shorewall check' command has been added that does a cursory
|
|
validation of the zones, interfaces, hosts, rules and policy files.</li>
|
|
</ul>
|
|
|
|
<p><b>2/18/2002 - 1.2.6 Debian Package is Available</b></p>
|
|
|
|
<p>See <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
|
|
<p><b>2/8/2002 - Shorewall 1.2.6 Released</b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>$-variables may now be used anywhere in the configuration files except
|
|
/etc/shorewall/zones.</li>
|
|
<li>The interfaces and hosts files now have their contents validated before
|
|
any changes are made to the existing Netfilter configuration. The
|
|
appearance of a zone name that isn't defined in /etc/shorewall/zones
|
|
causes "shorewall start" and "shorewall restart" to abort without
|
|
changing the Shorewall state. Unknown options in either file cause a
|
|
warning to be issued.</li>
|
|
<li>A problem occurring when BLACKLIST_LOGLEVEL was not set has been
|
|
corrected.</li>
|
|
</ul>
|
|
|
|
<p><b>2/4/2002 - Shorewall 1.2.5 Debian Package Available</b></p>
|
|
|
|
<p>see <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
|
|
<p><b>2/1/2002 - Shorewall 1.2.5 Released</b></p>
|
|
|
|
<p>Due to installation problems with Shorewall 1.2.4, I have released
|
|
Shorewall 1.2.5. Sorry for the rapid-fire development.</p>
|
|
|
|
<p>In version 1.2.5:</p>
|
|
<ul>
|
|
<li>The installation problems have been corrected.</li>
|
|
<li><a href="Documentation.htm#Masq">SNAT</a> is now supported.</li>
|
|
<li>A "shorewall version" command has been added</li>
|
|
<li>The default value of the STATEDIR variable in
|
|
/etc/shorewall/shorewall.conf has been changed to /var/lib/shorewall in
|
|
order to conform to the GNU/Linux File Hierarchy Standard, Version
|
|
2.2.</li>
|
|
</ul>
|
|
|
|
<p><b>1/28/2002 - Shorewall 1.2.4 Released</b></p>
|
|
<ul>
|
|
<li>The "fw" zone <a href="Documentation.htm#FW">may now be given a
|
|
different name</a>.</li>
|
|
<li>You may now place end-of-line comments (preceded by '#') in any of the
|
|
configuration files</li>
|
|
<li>There is now protection against against two state changing operations
|
|
occuring concurrently. This is implemented using the 'lockfile' utility
|
|
if it is available (lockfile is part of procmail); otherwise, a less
|
|
robust technique is used. The lockfile is created in the STATEDIR defined
|
|
in /etc/shorewall/shorewall.conf and has the name "lock".</li>
|
|
<li>"shorewall start" no longer fails if "detect" is specified in <a
|
|
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a> for an
|
|
interface with subnet mask 255.255.255.255.</li>
|
|
</ul>
|
|
|
|
<p><b>1/27/2002 - Shorewall 1.2.3 Debian Package Available</b> -- see <a
|
|
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>
|
|
|
|
<p><b>1/20/2002 - Corrected firewall script available </b></p>
|
|
|
|
<p>Corrects a problem with BLACKLIST_LOGLEVEL. See <a href="errata.htm">the
|
|
errata</a> for details.</p>
|
|
|
|
<p><b>1/19/2002 - Shorewall 1.2.3 Released</b></p>
|
|
|
|
<p>This is a minor feature and bugfix release. The single new feature is:</p>
|
|
<ul>
|
|
<li>Support for TCP MSS Clamp to PMTU -- This support is usually required
|
|
when the internet connection is via PPPoE or PPTP and may be enabled
|
|
using the <a href="Documentation.htm#ClampMSS">CLAMPMSS</a> option in
|
|
/etc/shorewall/shorewall.conf.</li>
|
|
</ul>
|
|
|
|
<p>The following problems were corrected:</p>
|
|
<ul>
|
|
<li>The "shorewall status" command no longer hangs.</li>
|
|
<li>The "shorewall monitor" command now displays the icmpdef chain</li>
|
|
<li>The CLIENT PORT(S) column in tcrules is no longer ignored</li>
|
|
</ul>
|
|
|
|
<p><b>1/18/2002 - Shorewall 1.2.2 packaged with new</b> <a
|
|
href="http://leaf.sourceforge.net">LEAF</a> <b>release</b></p>
|
|
|
|
<p>Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF
|
|
distribution that includes Shorewall 1.2.2. See <a
|
|
href="http://leaf.sourceforge.net/devel/jnilo">http://leaf.sourceforge.net/devel/jnilo</a>
|
|
for details.</p>
|
|
|
|
<p><b>1/11/2002 - Debian Package (.deb) Now Available -</b> Thanks to <a
|
|
href="mailto:lorenzo.martignoni@milug.org">Lorenzo Martignoni</a>, a 1.2.2
|
|
Shorewall Debian package is now available. There is a link to Lorenzo's site
|
|
from the <a href="download.htm">Shorewall download page</a>.</p>
|
|
|
|
<p><b>1/9/2002 - Updated 1.2.2 /sbin/shorewall available -</b> <a
|
|
href="/pub/shorewall/errata/1.2.2/shorewall">This corrected version</a>
|
|
restores the "shorewall status" command to health.</p>
|
|
|
|
<p><b>1/8/2002 - Shorewall 1.2.2 Released</b></p>
|
|
|
|
<p>In version 1.2.2</p>
|
|
<ul>
|
|
<li>Support for IP blacklisting has been added
|
|
<ul>
|
|
<li>You specify whether you want packets from blacklisted hosts dropped
|
|
or rejected using the <a
|
|
href="Documentation.htm#BLDisposition">BLACKLIST_DISPOSITION</a>
|
|
setting in /etc/shorewall/shorewall.conf</li>
|
|
<li>You specify whether you want packets from blacklisted hosts logged
|
|
and at what syslog level using the <a
|
|
href="Documentation.htm#BLLoglevel">BLACKLIST_LOGLEVEL</a> setting in
|
|
/etc/shorewall/shorewall.conf</li>
|
|
<li>You list the IP addresses/subnets that you wish to blacklist in <a
|
|
href="Documentation.htm#Blacklist">/etc/shorewall/blacklist</a></li>
|
|
<li>You specify the interfaces you want checked against the blacklist
|
|
using the new "<a href="Documentation.htm#BLInterface">blacklist</a>"
|
|
option in /etc/shorewall/interfaces.</li>
|
|
<li>The black list is refreshed from /etc/shorewall/blacklist by the
|
|
"shorewall refresh" command.</li>
|
|
</ul>
|
|
</li>
|
|
<li>Use of TCP RST replies has been expanded
|
|
<ul>
|
|
<li>TCP connection requests rejected because of a REJECT policy are now
|
|
replied with a TCP RST packet.</li>
|
|
<li>TCP connection requests rejected because of a protocol=all rule in
|
|
/etc/shorewall/rules are now replied with a TCP RST packet.</li>
|
|
</ul>
|
|
</li>
|
|
<li>A <a href="Documentation.htm#Logfile">LOGFILE</a> specification has
|
|
been added to /etc/shorewall/shorewall.conf. LOGFILE is used to tell the
|
|
/sbin/shorewall program where to look for Shorewall messages.</li>
|
|
</ul>
|
|
|
|
<p><b>1/5/2002 - New Parameterized Samples (<a
|
|
href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.2.0/"
|
|
target="_blank">version 1.2.0</a>) released.</b> These are minor updates to
|
|
the previously-released samples. There are two new rules added:</p>
|
|
<ul>
|
|
<li>Unless you have explicitly enabled Auth connections (tcp port 113) to
|
|
your firewall, these connections will be REJECTED rather than DROPPED.
|
|
This speeds up connection establishment to some servers.</li>
|
|
<li>Orphan DNS replies are now silently dropped.</li>
|
|
</ul>
|
|
|
|
<p>See the README file for upgrade instructions.</p>
|
|
|
|
<p><b>1/1/2002 - <u><font color="#FF6633">Shorewall Mailing List
|
|
Moving</font></u></b></p>
|
|
|
|
<p>The Shorewall mailing list hosted at <a
|
|
href="http://sourceforge.net">Sourceforge</a> is moving to Shorewall.net. If
|
|
you are a current subscriber to the list at Sourceforge, please <a
|
|
href="shorewall_mailing_list_migration.htm">see these instructions</a>. If
|
|
you would like to subscribe to the new list, visit <a
|
|
href="http://www.shorewall.net/mailman/listinfo/shorewall-users">http://www.shorewall.net/mailman/listinfo/shorewall-users</a>.</p>
|
|
|
|
<p><b>12/31/2001 - Shorewall 1.2.1 Released</b></p>
|
|
|
|
<p>In version 1.2.1:</p>
|
|
<ul>
|
|
<li><a href="Documentation.htm#LogUncleanOption">Logging of Mangled/Invalid
|
|
Packets</a> is added. </li>
|
|
<li>The <a href="IPIP.htm">tunnel script</a> has been corrected.</li>
|
|
<li>'shorewall show tc' now correctly handles tunnels.</li>
|
|
</ul>
|
|
|
|
<p><b>12/21/2001 - Shorewall 1.2.0 Released!</b> - <b>I couldn't resist
|
|
releasing 1.2 on 12/21/2001</b></p>
|
|
|
|
<p>Version 1.2 contains the following new features:</p>
|
|
<ul>
|
|
<li>Support for <a href="traffic_shaping.htm">Traffic
|
|
Control/Shaping</a></li>
|
|
<li>Support for <a href="Documentation.htm#Unclean">Filtering of
|
|
Mangled/Invalid Packets</a></li>
|
|
<li>Support for <a href="IPIP.htm">GRE Tunnels</a></li>
|
|
</ul>
|
|
|
|
<p>For the next month or so, I will continue to provide corrections to
|
|
version 1.1.18 as necessary so that current version 1.1.x users will not be
|
|
forced into a quick upgrade to 1.2.0 just to have access to bug fixes.</p>
|
|
|
|
<p>For those of you who have installed one of the Beta RPMS, you will need to
|
|
use the "--oldpackage" option when upgrading to 1.2.0:</p>
|
|
|
|
<blockquote>
|
|
<p>rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm</p>
|
|
</blockquote>
|
|
|
|
<p><b>12/19/2001 - Thanks to <a href="mailto:scowles@infohiiway.com">Steve
|
|
Cowles</a>, there is now a Shorewall mirror in Texas.</b> This web site is
|
|
mirrored at <a href="http://www.infohiiway.com/shorewall"
|
|
target="_top">http://www.infohiiway.com/shorewall</a> and the ftp site is at
|
|
<a
|
|
href="ftp://ftp.infohiiway.com/pub/mirrors/shorewall">ftp://ftp.infohiiway.com/pub/mirrors/shorewall</a>.
|
|
<b> </b></p>
|
|
|
|
<p><b>11/30/2001 - A new set of the parameterized <a
|
|
href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">Sample
|
|
Configurations</a> has been released</b>. In this version:</p>
|
|
<ul>
|
|
<li>Ping is now allowed between the zones.</li>
|
|
<li>In the three-interface configuration, it is now possible to configure
|
|
the internet services that are to be available to servers in the
|
|
DMZ. </li>
|
|
</ul>
|
|
|
|
<p><b>11/20/2001 - The current version of Shorewall is 1.1.18. </b></p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>The spelling of ADD_IP_ALIASES has been corrected in the shorewall.conf
|
|
file</li>
|
|
<li>The logic for deleting user-defined chains has been simplified so that
|
|
it avoids a bug in the LRP version of the 'cut' utility.</li>
|
|
<li>The /var/lib/lrpkg/shorwall.conf file has been corrected to properly
|
|
display the NAT entry in that file.</li>
|
|
</ul>
|
|
|
|
<p><b>11/19/2001 - Thanks to <a href="mailto:shorewall@timelord.sk">Juraj
|
|
Ontkanin</a>, there is now a Shorewall mirror in the Slovak Republic</b>. The
|
|
website is now mirrored at <a href="http://www.nrg.sk/mirror/shorewall"
|
|
target="_top">http://www.nrg.sk/mirror/shorewall</a> and the FTP site is
|
|
mirrored at <a
|
|
href="ftp://ftp.nrg.sk/mirror/shorewall">ftp://ftp.nrg.sk/mirror/shorewall</a>.</p>
|
|
|
|
<p><b>11/2/2001 - Announcing Shorewall Parameter-driven Sample
|
|
Configurations.</b> There are three sample configurations:</p>
|
|
<ul>
|
|
<li>One Interface -- for a standalone system.</li>
|
|
<li>Two Interfaces -- A masquerading firewall.</li>
|
|
<li>Three Interfaces -- A masquerading firewall with DMZ.</li>
|
|
</ul>
|
|
|
|
<p>Samples may be downloaded from <a
|
|
href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17">ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17</a>
|
|
. See the README file for instructions.</p>
|
|
|
|
<p><b>11/1/2001 - The current version of Shorewall is 1.1.17</b>. I
|
|
intend this to be the last of the 1.1 Shorewall releases.</p>
|
|
|
|
<p>In this version:</p>
|
|
<ul>
|
|
<li>The handling of <a href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>
|
|
has been corrected. </li>
|
|
</ul>
|
|
|
|
<p><b>10/22/2001 - The current version of Shorewall is 1.1.16</b>. In this
|
|
version:</p>
|
|
<ul>
|
|
<li>A new "shorewall show connections" command has been added.</li>
|
|
<li>In the "shorewall monitor" output, the currently tracked connections
|
|
are now shown on a separate page.</li>
|
|
<li>Prior to this release, Shorewall unconditionally added the external IP
|
|
adddress(es) specified in /etc/shorewall/nat. Beginning with version
|
|
1.1.16, a new parameter (<a
|
|
href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>) may be set to "no"
|
|
(or "No") to inhibit this behavior. This allows IP aliases created using
|
|
your distribution's network configuration tools to be used in static
|
|
NAT. </li>
|
|
</ul>
|
|
|
|
<p><b>10/15/2001 - The current version of Shorewall is 1.1.15.</b> In this
|
|
version:</p>
|
|
<ul>
|
|
<li>Support for nested zones has been improved. See <a
|
|
href="Documentation.htm#Nested">the documentation</a> for details</li>
|
|
<li>Shorewall now correctly checks the alternate configuration directory
|
|
for the 'zones' file.</li>
|
|
</ul>
|
|
|
|
<p><b>10/4/2001 - The current version of Shorewall is 1.1.14.</b> In this
|
|
version</p>
|
|
<ul>
|
|
<li>Shorewall now supports alternate configuration directories. When an
|
|
alternate directory is specified when starting or restarting Shorewall
|
|
(e.g., "shorewall -c /etc/testconf restart"), Shorewall will first look
|
|
for configuration files in the alternate directory then in
|
|
/etc/shorewall. To create an alternate configuration simply:<br>
|
|
1. Create a New Directory<br>
|
|
2. Copy to that directory any of your configuration files that you want
|
|
to change.<br>
|
|
3. Modify the copied files as needed.<br>
|
|
4. Restart Shorewall specifying the new directory.</li>
|
|
<li>The rules for allowing/disallowing icmp echo-requests (pings) are now
|
|
moved after rules created when processing the rules file. This allows you
|
|
to add rules that selectively allow/deny ping based on source or
|
|
destination address.</li>
|
|
<li>Rules that specify multiple client ip addresses or subnets no longer
|
|
cause startup failures.</li>
|
|
<li>Zone names in the policy file are now validated against the zones
|
|
file.</li>
|
|
<li>If you have <a href="Documentation.htm#MangleEnabled">packet
|
|
mangling</a> support enabled, the "<a
|
|
href="Documentation.htm#Interfaces">norfc1918</a>" interface option now
|
|
logs and drops any incoming packets on the interface that have an RFC
|
|
1918 destination address.</li>
|
|
</ul>
|
|
|
|
<p><b>9/12/2001 - The current version of Shorewall is 1.1.13</b>. In this
|
|
version</p>
|
|
<ul>
|
|
<li>Shell variables can now be used to parameterize Shorewall rules.</li>
|
|
<li>The second column in the hosts file may now contain a comma-separated
|
|
list.<br>
|
|
<br>
|
|
Example:<br>
|
|
sea
|
|
eth0:130.252.100.0/24,206.191.149.0/24</li>
|
|
<li>Handling of multi-zone interfaces has been improved. See the <a
|
|
href="Documentation.htm#Interfaces">documentation for the
|
|
/etc/shorewall/interfaces file</a>.</li>
|
|
</ul>
|
|
|
|
<p><b>8/28/2001 - The current version of Shorewall is 1.1.12</b>. In this
|
|
version</p>
|
|
<ul>
|
|
<li>Several columns in the rules file may now contain comma-separated
|
|
lists.</li>
|
|
<li>Shorewall is now more rigorous in parsing the options in
|
|
/etc/shorewall/interfaces.</li>
|
|
<li>Complementation using "!" is now supported in rules.</li>
|
|
</ul>
|
|
|
|
<p><b>7/28/2001 - The current version of Shorewall is 1.1.11</b>. In this
|
|
version</p>
|
|
<ul>
|
|
<li>A "shorewall refresh" command has been added to allow for refreshing
|
|
the rules associated with the broadcast address on a dynamic interface.
|
|
This command should be used in place of "shorewall restart" when the
|
|
internet interface's IP address changes.</li>
|
|
<li>The /etc/shorewall/start file (if any) is now processed after all
|
|
temporary rules have been deleted. This change prevents the accidental
|
|
removal of rules added during the processing of that file.</li>
|
|
<li>The "dhcp" interface option is now applicable to firewall interfaces
|
|
used by a DHCP server running on the firewall.</li>
|
|
<li>The RPM can now be built from the .tgz file using "rpm -tb" </li>
|
|
</ul>
|
|
|
|
<p><b>7/6/2001 - The current version of Shorewall is 1.1.10.</b> In this
|
|
version</p>
|
|
<ul>
|
|
<li>Shorewall now enables Ipv4 Packet Forwarding by default. Packet
|
|
forwarding may be disabled by specifying IP_FORWARD=Off in
|
|
/etc/shorewall/shorewall.conf. If you don't want Shorewall to enable or
|
|
disable packet forwarding, add IP_FORWARDING=Keep to your
|
|
/etc/shorewall/shorewall.conf file.</li>
|
|
<li>The "shorewall hits" command no longer lists extraneous service names
|
|
in its last report.</li>
|
|
<li>Erroneous instructions in the comments at the head of the firewall
|
|
script have been corrected.</li>
|
|
</ul>
|
|
|
|
<p><b>6/23/2001 - The current version of Shorewall is 1.1.9.</b> In this
|
|
version</p>
|
|
<ul>
|
|
<li>The "tunnels" file <u>really</u> is in the RPM now.</li>
|
|
<li>SNAT can now be applied to port-forwarded connections.</li>
|
|
<li>A bug which would cause firewall start failures in some dhcp
|
|
configurations has been fixed.</li>
|
|
<li>The firewall script now issues a message if you have the name of an
|
|
interface in the second column in an entry in /etc/shorewall/masq and
|
|
that interface is not up.</li>
|
|
<li>You can now configure Shorewall so that it <a
|
|
href="Documentation.htm#NatEnabled">doesn't require the NAT and/or mangle
|
|
netfilter modules</a>.</li>
|
|
<li>Thanks to Alex Polishchuk, the "hits" command from seawall is now
|
|
in shorewall.</li>
|
|
<li>Support for <a href="IPIP.htm">IPIP tunnels</a> has been added.</li>
|
|
</ul>
|
|
|
|
<p><b>6/18/2001 - The current version of Shorewall is 1.1.8</b>. In this
|
|
version</p>
|
|
<ul>
|
|
<li>A typo in the sample rules file has been corrected.</li>
|
|
<li>It is now possible to restrict masquerading by <a
|
|
href="Documentation.htm#Masq">destination host or subnet.</a></li>
|
|
<li>It is now possible to have static <a href="NAT.htm#LocalPackets">NAT
|
|
rules applied to packets originating on the firewall itself</a>.</li>
|
|
</ul>
|
|
|
|
<p><b>6/2/2001 - The current version of Shorewall is 1.1.7.</b> In this
|
|
version</p>
|
|
<ul>
|
|
<li>The TOS rules are now deleted when the firewall is stopped.</li>
|
|
<li>The .rpm will now install regardless of which version of iptables is
|
|
installed.</li>
|
|
<li>The .rpm will now install without iproute2 being installed.</li>
|
|
<li>The documentation has been cleaned up.</li>
|
|
<li>The sample configuration files included in Shorewall have been
|
|
formatted to 80 columns for ease of editing on a VGA console.</li>
|
|
</ul>
|
|
|
|
<p><b>5/25/2001 - The current version of Shorewall is 1.1.6</b>. In this
|
|
version</p>
|
|
<ul>
|
|
<li><a href="Documentation.htm#lograte">You may now rate-limit the packet
|
|
log.</a></li>
|
|
<li>Previous versions of Shorewall have an implementation of Static NAT
|
|
which violates the principle of least surprise. NAT only occurs for
|
|
packets arriving at (DNAT) or send from (SNAT) the interface named in the
|
|
INTERFACE column of /etc/shorewall/nat. Beginning with version 1.1.6, NAT
|
|
effective regardless of which interface packets come from or are destined
|
|
to. To get compatibility with prior versions, I have added a new "ALL <a
|
|
href="NAT.htm#AllInterFaces">"ALL INTERFACES" column to
|
|
/etc/shorewall/nat</a>. By placing "no" or "No" in the new column, the
|
|
NAT behavior of prior versions may be retained. </li>
|
|
<li>The treatment of <a href="IPSEC.htm#RoadWarrior">IPSEC Tunnels where
|
|
the remote gateway is a standalone system has been improved</a>.
|
|
Previously, it was necessary to include an additional rule allowing UDP
|
|
port 500 traffic to pass through the tunnel. Shorewall will now create
|
|
this rule automatically when you place the name of the remote peer's zone
|
|
in a new GATEWAY ZONE column in /etc/shorewall/tunnels. </li>
|
|
</ul>
|
|
|
|
<p><b>5/20/2001 - The current version of Shorewall is 1.1.5.</b> In this
|
|
version</p>
|
|
<ul>
|
|
<li><a href="Documentation.htm#modules">You may now pass parameters when
|
|
loading netfilter modules and you can specify the modules to
|
|
load.</a></li>
|
|
<li>Compressed modules are now loaded. This requires that you modutils
|
|
support loading compressed modules.</li>
|
|
<li><a href="Documentation.htm#TOS">You may now set the Type of Service
|
|
(TOS) field in packets.</a></li>
|
|
<li>Corrected rules generated for port redirection (again).</li>
|
|
</ul>
|
|
|
|
<p><b>5/10/2001 - The current version of Shorewall is 1.1.4.</b> In this
|
|
version</p>
|
|
<ul>
|
|
<li><a href="Documentation.htm#Conf">Accepting RELATED connections is now
|
|
optional.</a></li>
|
|
<li>Corrected problem where if "shorewall start" aborted early (due to
|
|
kernel configuration errors for example), superfluous 'sed' error
|
|
messages were reported.</li>
|
|
<li>Corrected rules generated for port redirection.</li>
|
|
<li>The order in which iptables kernel modules are loaded has been
|
|
corrected (Thanks to Mark Pavlidis). </li>
|
|
</ul>
|
|
|
|
<p><b>4/28/2001 - The current version of Shorewall is 1.1.3.</b> In this
|
|
version</p>
|
|
<ul>
|
|
<li>Correct message issued when Proxy ARP address added (Thanks to Jason
|
|
Kirtland).</li>
|
|
<li>/tmp/shorewallpolicy-$$ is now removed if there is an error while
|
|
starting the firewall.</li>
|
|
<li>/etc/shorewall/icmp.def and /etc/shorewall/common.def are now used to
|
|
define the icmpdef and common chains unless overridden by the presence of
|
|
/etc/shorewall/icmpdef or /etc/shorewall/common.</li>
|
|
<li>In the .lrp, the file /var/lib/lrpkg/shorwall.conf has been corrected.
|
|
An extra space after "/etc/shorwall/policy" has been removed and
|
|
"/etc/shorwall/rules" has been added.</li>
|
|
<li>When a sub-shell encounters a fatal error and has stopped the firewall,
|
|
it now kills the main shell so that the main shell will not continue.</li>
|
|
<li>A problem has been corrected where a sub-shell stopped the firewall and
|
|
main shell continued resulting in a perplexing error message referring to
|
|
"common.so" resulted.</li>
|
|
<li>Previously, placing "-" in the PORT(S) column in /etc/shorewall/rules
|
|
resulted in an error message during start. This has been corrected.</li>
|
|
<li>The first line of "install.sh" has been corrected -- I had
|
|
inadvertently deleted the initial "#".</li>
|
|
</ul>
|
|
|
|
<p><b>4/12/2001 - The current version of Shorewall is 1.1.2.</b> In this
|
|
version</p>
|
|
<ul>
|
|
<li>Port redirection now works again.</li>
|
|
<li>The icmpdef and common chains <a href="Documentation.htm#Icmpdef">may
|
|
now be user-defined</a>.</li>
|
|
<li>The firewall no longer fails to start if "routefilter" is specified for
|
|
an interface that isn't started. A warning message is now issued in this
|
|
case.</li>
|
|
<li>The LRP Version is renamed "shorwall" for 8,3 MSDOS file system
|
|
compatibility.</li>
|
|
<li>A couple of LRP-specific problems were corrected.</li>
|
|
</ul>
|
|
|
|
<p><b>4/8/2001 - Shorewall is now affiliated with the <a
|
|
href="http://leaf.sourceforge.net">Leaf Project</a></b> <a
|
|
href="http://leaf.sourceforge.net"><img src="images/leaflogo.gif"
|
|
alt="Leaf Logo" border="0" height="36" width="49" /></a></p>
|
|
|
|
<p><b>4/5/2001 - The current version of Shorewall is 1.1.1. In this
|
|
version:</b></p>
|
|
<ul>
|
|
<li>The common chain is traversed from INPUT, OUTPUT and FORWARD before
|
|
logging occurs</li>
|
|
<li>The source has been cleaned up dramatically</li>
|
|
<li>DHCP DISCOVER packets with RFC1918 source addresses no longer generate
|
|
log messages. Linux DHCP clients generate such packets and it's annoying
|
|
to see them logged. </li>
|
|
</ul>
|
|
|
|
<p><b>3/25/2001 - The current version of Shorewall is 1.1.0. In this
|
|
version:</b></p>
|
|
<ul>
|
|
<li>Log messages now indicate the packet disposition.</li>
|
|
<li>Error messages have been improved.</li>
|
|
<li>The ability to define zones consisting of an enumerated set of hosts
|
|
and/or subnetworks has been added.</li>
|
|
<li>The zone-to-zone chain matrix is now sparse so that only those chains
|
|
that contain meaningful rules are defined.</li>
|
|
<li>240.0.0.0/4 and 169.254.0.0/16 have been added to the source
|
|
subnetworks whose packets are dropped under the <i>norfc1918</i>
|
|
interface option.</li>
|
|
<li>Exits are now provided for executing an user-defined script when a
|
|
chain is defined, when the firewall is initialized, when the firewall is
|
|
started, when the firewall is stopped and when the firewall is
|
|
cleared.</li>
|
|
<li>The Linux kernel's route filtering facility can now be specified
|
|
selectively on network interfaces.</li>
|
|
</ul>
|
|
|
|
<p><b>3/19/2001 - The current version of Shorewall is 1.0.4. This
|
|
version:</b></p>
|
|
<ul>
|
|
<li>Allows user-defined zones. Shorewall now has only one pre-defined zone
|
|
(fw) with the remaining zones being defined in the new configuration file
|
|
/etc/shorewall/zones. The /etc/shorewall/zones file released in this
|
|
version provides behavior that is compatible with Shorewall
|
|
1.0.3. </li>
|
|
<li>Adds the ability to specify logging in entries in the
|
|
/etc/shorewall/rules file.</li>
|
|
<li>Correct handling of the icmp-def chain so that only ICMP packets are
|
|
sent through the chain.</li>
|
|
<li>Compresses the output of "shorewall monitor" if awk is installed.
|
|
Allows the command to work if awk isn't installed (although it's not
|
|
pretty).</li>
|
|
</ul>
|
|
|
|
<p><b>3/13/2001 - The current version of Shorewall is 1.0.3. This is a
|
|
bug-fix release with no new features.</b></p>
|
|
<ul>
|
|
<li>The PATH variable in the firewall script now includes /usr/local/bin
|
|
and /usr/local/sbin.</li>
|
|
<li>DMZ-related chains are now correctly deleted if the DMZ is deleted.</li>
|
|
<li>The interface OPTIONS for "gw" interfaces are no longer ignored.</li>
|
|
</ul>
|
|
|
|
<p><b>3/8/2001 - The current version of Shorewall is 1.0.2. It supports an
|
|
additional "gw" (gateway) zone for tunnels and it supports IPSEC tunnels with
|
|
end-points on the firewall. There is also a .lrp available now.</b></p>
|
|
</body>
|
|
</html>
|