mirror of
https://gitlab.com/shorewall/code.git
synced 2025-01-08 22:58:50 +01:00
Update News again
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@9231 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
62daa5c90c
commit
88c2361323
@ -32,9 +32,13 @@ License</a></span>".
|
||||
<p><strong>2008-12-31 Shorewall 4.2.4</strong></p>
|
||||
<p><strong></strong></p>
|
||||
<pre>1) In 4.2.4, two new packages are included:<br><br> a) Shorewall6 - analagous to Shorewall-common but handles IPv6<br> rather than IPv4.<br><br> b) Shorewall6-lite - analagous to Shorewall-lite but handles IPv6<br> rather than IPv4.<br><br> The packages store their configurations in /etc/shorewall6/ and<br> /etc/shorewall6-lite/ respectively. <br><br> The fact that the packages are separate from their IPv4 counterparts<br> means that you control IPv4 and IPv6 traffic separately (the same<br> way that Netfilter does). Starting/Stopping the firewall for one<br> address family has no effect on the other address family.<br><br> For additional information, see<br> http://www.shorewall.net/IPV6Support.html.<br><br> Other features of Shorewall6 are:<br><br> a) There is no NAT of any kind (most people see this as a giant step<br> forward). When an ISP assigns you a public IPv6 address, you are<br> actually assigned an IPv6 'prefix' which is like an IPv4<br> subnet. A 64-bit prefix allows 4 billion squared individual hosts<br> (the size of the current IPv4 address space squared).<br><br> b) The default zone type is ipv6.<br><br> c) The currently-supported interface options in Shorewall6 are:<br><br> blacklist<br> bridge<br> dhcp<br> nosmurfs (traps multicast and Subnet-router anycast addresses<br> used as the packet source address).<br> optional<br> routeback<br> sourceroute<br> tcpflags<br><br> Other features of Shorewall6 are:<br><br> a) There is no NAT of any kind (most people see this as a giant step<br> forward). When an ISP assigns you a public IPv6 address, you are<br> actually assigned an IPv6 'prefix' which is like an IPv4<br> subnet. A 64-bit prefix allows 4 billion squared individual hosts<br> (the size of the current IPv4 address space squared).<br><br> b) The default zone type is ipv6.<br><br> c) The currently-supported interface options in Shorewall6 are:<br><br> blacklist<br> bridge<br> dhcp<br> nosmurfs (traps multicast and Subnet-router anycast addresses<br> used as the packet source address).<br> optional<br> routeback<br> sourceroute<br> tcpflags<br> mss<br> forward (setting it to 0 makes the router behave like a host<br> on that interface rather than like a router).<br><br> d) The currently-supported host options in Shorewall6 are:<br><br> blacklist<br> routeback<br> tcpflags<br><br> e) Traffic Shaping is disabled by default. The tcdevices and<br> tcclasses files are address-family independent so<br> to use the Shorewall builtin Traffic Shaper, TC_ENABLED=Internal<br> should be specified in Shorewall or in Shorewall6 but not in<br> both. In the configuration where the internal traffic shaper is<br> not enabled, CLEAR_TC=No should be specified.<br><br> tcfilters are not available in Shorewall6.<br><br> f) When both an interface and an address or address list need to<br> be specified in a rule, the address or list must be enclosed in<br> angle brackets. Example:<br><br> #ACTION SOURCE DEST<br> ACCEPT net:eth0:<2001:19f0:feee::dead:beef:cafe> dmz<br><br> Note that this includes MAC addresses as well as IPv6 addresses.<br><br> The HOSTS column in /etc/shorewall6/hosts also uses this<br> convention:<br><br> #ZONE HOSTS OPTIONS<br> chat6 eth0:<2001:19f0:feee::dead:beef:cafe><br><br> Even when an interface is not specified, it is permitted to<br> enclose addresses in <> to improve readability. Example:<br><br> #ACTION SOURCE DEST<br> ACCEPT net:<2001:1::1> $FW<br><br> g) The options available in shorewall6.conf are a subset of those<br> available in shorewall.conf.<br><br> h) The Socket6.pm Perl module is required if you include DNS names<br> in your Shorewall6 configuration. Note that it is loaded the<br> first time that a DNS name is encountered so if it is missing,<br> you get a message similar to this one:<br><br> ...<br> Checking /etc/shorewall6/rules...<br> Can't locate Socket6.pm in @INC (@INC contains: /root ...<br> teastep@ursa:~/Configs/standalone6$ <br></pre>
|
||||
<p><strong>2008-12-16 Shorewall 4.2.3</strong></p>
|
||||
<p><strong></strong></p>
|
||||
<pre>Problems corrected in Shorewall 4.2.3<br><br>1) Previously, Shorewall would allow compilation for export of a<br> script named 'shorewall' with the unfortunate side effect that<br> the 'shorewall.conf' file was overwritten. Scripts named<br> 'shorewall' now cause a fatal error to be raised.<br><br>2) Previously, Shorewall-perl attempted to do Shell variable<br> substitution on the first line in /etc/shorewall/compile.<br><br>3) Following the Netfilter tradition, the IPP2P maintainer has made an<br> incompatible syntax change (the --ipp2p option has been<br> removed). Shorewall has always used "-m ipp2p --ipp2p" when<br> detecting the presence of IPP2P support.<br><br> Shorewall-common and Shorewall-perl have been modified to use<br> "-m ipp2p --edk" instead.<br><br>4) When Extended Conntrack Match support was available, Shorewall-perl<br> would create invalid iptables-restore input for certain DNAT rules.<br><br>5) An optimization in all Shorewall-perl 4.2 versions could cause<br> undesirable side effects. The optimization deleted the<br> <interface>_in and <interface>_fwd chains and moved their rules<br> to the appropriate rules chain (a <zone>2<xxx> chain).<br><br> This worked badly in cases where a zone was associated with more<br> than one interface. Rules could be duplicated or, worse, a rule<br> that was intended for only input from one of the interfaces would<br> be applied to input from all of the zone's interfaces.<br><br> This problem has been corrected so that an interface-related<br> chains is only deleted if:<br><br> a) the chain has no rules in it; or<br> b) the interface is associated with only one zone and that zone is<br> associated with only that interface in which case it is safe to<br> move the rules.<br><br>Other changes in Shorewall 4.2.3<br><br>1) Except with the -e option is specified, the Shorewall-perl compiler<br> now verifies user/group names appearing in the USER/GROUP column of<br> the rules file.<br><br>2) The output of 'shorewall dump' now includes the output from<br> 'netstat -tunap'.<br><br>3) Shorewall-perl now accepts '+' as an interface name in<br> /etc/shorewall/interfaces. That name matches any interface and is<br> useful for defining a zone that will match any interface that might<br> be added after Shorewall is started.<br><br> A couple of words of caution are in order.<br><br> a) Because '+' matches any interface name, Shorewall cannot<br> verify interface names appearing in other files when '+' is<br> defined in /etc/shorewall/interfaces.<br><br> b) The zone assigned to '+' must be the last one defined in<br> /etc/shorewall/zones.<br><br>4) Shorewall-perl now uses the iptables --goto parameter in obvious<br> cases.<br><br>5) The 'reset' command now allows you to reset the packet and byte<br> counter on individual chains:<br><br> shorewall reset chain1 chain2 ...<br> shorewall-lite reset chain1 chain2 ...<br></pre>
|
||||
<p><strong>2008-11-20 Shorewall 4.2.2</strong></p>
|
||||
<p><strong></strong></p>
|
||||
<pre>Problems corrected in Shorewall 4.2.2<br><br>1) Shorewall-perl now insures that each line copied from a<br> configuration file or user exit is terminated with a newline<br> character.<br><br>2) When ipranges were used to define zones, Shorewall-perl could<br> generate invalid iptables-restore input if 'Repeat Match' was not<br> available. Repeat Match is not a true match -- it rather is a<br> feature of recent iptables releases that allows a match to be<br> repeated within a rule.<br><br>3) With Shorewall-perl, if a destination port list had exactly 16<br> ports, where a port-range counts as two ports, then Shorewall-perl<br> would fail to split the rule into multiple rules and an<br> iptables-restore error would result.<br><br>4) The change to Shorewall-perl in 4.2.1 that promised iptables 1.4.1<br> compatibility contained a typo that prevented it from working<br> correctly.<br><br>5) If a no-NAT rule (DNAT-, ACCEPT+, NONAT) included a destination IP<br> address and no zone name in the DEST column, Shorewall-perl would<br> reject the rule. If a zone name was specified, Shorewall-perl <br> would issue a Warning message.<br><br>6) Previously, if Extended conntrack match support was available, a<br> DNAT rule that specified a server port but no destination port <br> would generate invalid iptables-restore input. <br><br>Other changes in Shorewall 4.2.2<br><br>1) A macro supporting JAP (anonymization protocol) has been added.<br> It can be used as any other macro (e.g., JAP/ACCEPT) in the rules<br> file.<br><br>2) A macro supporting DAAP (Digital Audio Access Protocol) has been added.<br> It can be used as any other macro (e.g., DAAP/ACCEPT) in the rules<br> file.<br><br>3) A macro supporting DCC (Distributed Checksum Clearinghouse) has been<br> added. It can be used as any other macro (e.g., DCCP/ACCEPT) in the<br> rules file.<br><br>4) A macro supporting GNUnet (secure peer-to-peer networking) has been<br> added. It can be used as any other macro (e.g., GNUnet/ACCEPT) in the<br> rules file.<br><br>5) In 4.2.1, a single capability ("Extended conntrack match support")<br> was used both to control the use of --ctorigport and to trigger use<br> of the new syntax for inversion of --ctorigdst (e.g., "!<br> --ctorigdst ..."). In 4.2.2, these are controlled by two separate<br> capabilities. If you use a capabilities file when compiling your<br> configuration, be sure to generate a new one after installing<br> 4.2.2.<br></pre>
|
||||
Problems corrected in Shorewall 4.2.2
|
||||
<pre><br>1) Shorewall-perl now insures that each line copied from a<br> configuration file or user exit is terminated with a newline<br> character.<br><br>2) When ipranges were used to define zones, Shorewall-perl could<br> generate invalid iptables-restore input if 'Repeat Match' was not<br> available. Repeat Match is not a true match -- it rather is a<br> feature of recent iptables releases that allows a match to be<br> repeated within a rule.<br><br>3) With Shorewall-perl, if a destination port list had exactly 16<br> ports, where a port-range counts as two ports, then Shorewall-perl<br> would fail to split the rule into multiple rules and an<br> iptables-restore error would result.<br><br>4) The change to Shorewall-perl in 4.2.1 that promised iptables 1.4.1<br> compatibility contained a typo that prevented it from working<br> correctly.<br><br>5) If a no-NAT rule (DNAT-, ACCEPT+, NONAT) included a destination IP<br> address and no zone name in the DEST column, Shorewall-perl would<br> reject the rule. If a zone name was specified, Shorewall-perl <br> would issue a Warning message.<br><br>6) Previously, if Extended conntrack match support was available, a<br> DNAT rule that specified a server port but no destination port <br> would generate invalid iptables-restore input. <br><br>Other changes in Shorewall 4.2.2<br><br>1) A macro supporting JAP (anonymization protocol) has been added.<br> It can be used as any other macro (e.g., JAP/ACCEPT) in the rules<br> file.<br><br>2) A macro supporting DAAP (Digital Audio Access Protocol) has been added.<br> It can be used as any other macro (e.g., DAAP/ACCEPT) in the rules<br> file.<br><br>3) A macro supporting DCC (Distributed Checksum Clearinghouse) has been<br> added. It can be used as any other macro (e.g., DCCP/ACCEPT) in the<br> rules file.<br><br>4) A macro supporting GNUnet (secure peer-to-peer networking) has been<br> added. It can be used as any other macro (e.g., GNUnet/ACCEPT) in the<br> rules file.<br><br>5) In 4.2.1, a single capability ("Extended conntrack match support")<br> was used both to control the use of --ctorigport and to trigger use<br> of the new syntax for inversion of --ctorigdst (e.g., "!<br> --ctorigdst ..."). In 4.2.2, these are controlled by two separate<br> capabilities. If you use a capabilities file when compiling your<br> configuration, be sure to generate a new one after installing<br> 4.2.2.<br></pre>
|
||||
<p><strong>2008-10-25 Shorewall 4.2.1<br>
|
||||
</strong><strong></strong></p>
|
||||
<pre>Problems corrected in Shorewall 4.2.1<br><br>1) A description of the CONNBYTES column has been added to<br> shorewall-tcrules(5).<br><br>2) Previously, Shorewall-perl would accept zero as the <max> value in<br> the CONNBYTES column of tcrules even when the <min> field was<br> non-zero. A value of zero for <max> was equivalent to omitting<br> <max>.<br><br>3) iptables 1.4.1 discontinued support of syntax generated by<br> shorewall in some cases. Shorewall now detects when the new syntax<br> is required and uses it instead.<br><br>4) The Shorewall-perl implementation of the LENGTH column in<br> /etc/shorewall/tcrules was incomplete with the result that <br> all LENGTH rules matched. Thanks to Lennart Sorensen for the patch.<br><br>5) The 'export' command no longer fails with the error:<br><br> /sbin/shorewall: 1413: Syntax error: "(" unexpected (expecting "fi")<br><br>Other changes in Shorewall 4.2.1<br><br>1) With the recent renewed interest in DOS attacks, it seems<br> appropriate to have connection limiting support in Shorewall. To<br> that end, a CONNLIMIT column has been added to both the policy and<br> rules files.<br><br> The content of these columns is of the format<br><br> [!] <limit>[:<mask>]<br><br> where<br><br> <limit> is the limit on simultaneous TCP connections.<br><br> <mask> specifies the size of the network to which<br> the limit applies and is specified as a<br> CIDR mask length. The default value for<br> <mask> is 32 which means that each remote<br> IP address can have <limit> TCP connections<br> active at once.<br><br> ! Not allowed in the policy file. In the rules file, it<br> causes connections to match when the number of<br> current connections exceeds <limit>.<br> <br> When specified in the policy file, the limit is enforced on all<br> connections that are subject to the given policy (just like<br> LIMIT:BURST). The limit is checked on new connections before the<br> connection is passed through the rules in the NEW section of the<br> rules file.<br><br> It is important to note that while the limit is only checked for<br> those destinations specified in the DEST column, the number of<br> current connections is calculated over all destinations and not<br> just the destination specified in the DEST column.<br><br> Use of this feature requires the connlimit match capability in your<br> kernel and iptables. If you use a capabilities file when compiling<br> your Shorewall configuration(s), then you need to regenerate the<br> file using Shorewall or Shorewall-lite 4.2.1.<br><br>2) Shorewall now supports time/date restrictions on entries in the <br> rules file via a new TIME column.<br><br> The contents of this column is a series of one or more "time<br> elements" separated by apersands ("&"). Possible time elements are:<br><br> utc Times are expressed in Greenwich Mean Time.<br> localtz Times are expressed in local civil time (default)<br> timestart=hh:mm[:ss]<br> timestop=hh:mm[:ss] Start and stop time of day for rule<br> weekdays=ddd[,ddd]... where ddd is Mon,Tue,Wed,Thu,Fri,Sat or<br> Sun<br> monthdays=dd[,dd]... where dd is an ordinal day of the month.<br> datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]<br> datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]<br> where yyyy = Year<br> first mm = Month<br> dd = Day<br> hh = Hour<br> 2nd mm = Minute<br> ss = Second<br><br> Examples:<br><br> 1) utc&timestart=10:00&timestop=12:00<br><br> Between 10am and 12 noon each day, GMT<br><br> 2) datestart=2008-11-01T12:00<br><br> Beginning November 1, 2008 at noon LCT.<br><br> Use of this feature requires the time match capability in your<br> kernel and iptables. If you use a capabilities file when compiling<br> your Shorewall configuration(s), then you need to regenerate the<br> file using Shorewall or Shorewall-lite 4.2.1.<br></pre>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user