shorewall_code/STABLE/releasenotes.txt

This is a minor release of Shorewall.

Problems Corrected since version 1.4.6:

1) Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was
   being tested before it was set.

2) Corrected handling of MAC addresses in the SOURCE column of the
   tcrules file. Previously, these addresses resulted in an invalid
   iptables command.

3) 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.

4) 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.
   
   The firewall script has been modified to eliminate the error
   messages.

5) Interface-specific dynamic blacklisting chains are now displayed by
    "shorewall monitor" on the "Dynamic Chains" page (previously named
    "Dynamic Chain").

6) Thanks to Henry Yang, LOGRATE and LOGBURST now work again.

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.

8) When ADD_SNAT_ALIASES=Yes in shorewall.conf, the following entry in
   /etc/shorewall/masq resulted in a startup error:

   eth0	eth1	 206.124.146.20-206.124.146.24

9) 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).

10) Shorewall will now load module files that are formed from the
    module name by appending ".o.gz".

11) 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.

12) The rfc1918 file has been updated to reflect recent allocations.

13) The documentation of the USERSETS column in the rules file has been
    corrected.

14) If there is no policy defined for the zones specified in a rule,
    the firewall script previously encountered a shell syntax error:

	[: NONE: unexpected operator

    Now, the absence of a policy generates an error message and the
    firewall is stopped:

        No policy defined from zone <source> to zone <dest>

15) 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:

    Loading /usr/share/shorewall/functions...
    Processing /etc/shorewall/params ...
    Processing /etc/shorewall/shorewall.conf...
    Giving up on lock file /var/lib/shorewall/lock
    Shorewall Not Started

    Shorewall now reports a fatal error if neither of these two files
    exist and correctly removes the lock file.

16) The order of processing the various options has been changed such
    that blacklist entries now take precedence over the 'dhcp'
    interface setting. 

17) The log message generated from the 'logunclean' interface option
    has been changed to reflect a disposition of LOG rather than DROP.

18) 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.

    Example:

    ACCEPT fw  net:192.0.2.12 tcp 23 - - - vladimir:

19) The /etc/shorewall/masq file has had the spurious "/" character at
    the front removed.

Migration Issues:

1) IP Traffic Accounting is changed from Snapshot 20030813. 

2) The Uset Set capability introduced in SnapShot 20030821 has
   changed -- see the User Set page for details.

3) The per-interface dynamic blacklisting facility from previous 1.4.6
   Snapshots has been removed. The implications of the facility for 
   users with dial-up internet connections were too complicated to
   document adaquately. My apologies for unleashing this half-baked
   idea on the user base.

New Features:

1) The 2.6 series of Linux kernels will not support the 'unclean'
   match extension except in Patch-O-Matic. In keeping with the
   Shorewall policy of not supporting netfilter extensions that are
   only available in Patch-O-Matic, the 'dropunclean' and
   'logunclean' interface options will be removed in a future
   release. In the 1.4.7 release, they are flagged with a warning.

2) Thanks to Steve Herber, the help command can now give
   command-specific help.

3) A new option "ADMINISABSENTMINDED" has been added to
   /etc/shorewall/shorewall.conf. This option has a default value of
   "No" for existing Shorewall users who are upgrading to this release.
   With this setting, Shorewall's 'stopped' state continues as it has
   been; namely, in the stopped state only traffic to/from hosts listed
   in /etc/shorewall/routestopped is accepted.

   The default for new users installing Shorewall for the first time is
   ADMINISABSENTMINDED=Yes.With that setting, in addition to traffic
   to/from the hosts listed in /etc/shorewall/routestopped, Shorewall
   will allow:

	a) All traffic originating from the firewall itself; and
	b) All traffic that is part of or related to an already-existing
           connection.

   In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
   entered through an ssh session will not kill the session.

   Note though that it is still possible for people to shoot themselves
   in the foot.

   Example:

   /etc/shorewall/nat:

   206.124.146.178	eth0:0	192.168.1.5	

   /etc/shorewall/rules:

   ACCEPT	net	loc:192.168.1.5	tcp	22
   ACCEPT	loc	fw		tcp	22

   I ssh into 206.124.146.178 which establishes an SSH connection with
   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 stopping, Shorewall removes eth0:0 which kills my
   SSH connection to 192.168.1.5!!!

4) 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.

   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
   implement your security policy regarding traffic to/from those
   systems.

   In the /etc/shorewall/tunnels file, you can have entries of the
   form:

   # TYPE			ZONE	GATEWAY		GATEWAY ZONE
   generic:<protocol>[:<port>]	<zone>	<ip address>	<gateway zones>

   where:

       <protocol>	is the protocol used by the tunnel
       <port>		if the protocol is 'udp' or 'tcp' then this
			is the destination port number used by the
			tunnel.
       <zone>		is the zone of the remote tunnel gateway
       <ip address>	is the IP address of the remote tunnel
			gateway.
       <gateway zone>	Optional. A comma-separated list of zone names.
			If specified, the remote gateway is to be
			considered part of these zones.

5) 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 of 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.

6) 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.

7) An /etc/shorewall/accounting file has been added to allow for 
   traffic accounting..

   The accounting rules are placed in a chain called "accounting" and
   can thus be displayed using "shorewall show accounting".

   The file has the following columns:

       ACTION	     -  What to do when a match is found. Possible
		        values are:

			COUNT - Simply count the match and continue
			        trying to match the packet with the
			        following accounting rules.

			DONE  - Count the match and don't attempt to
				match any following accounting rules.

			<chain> - The name of a chain to jump to.
				  Shorewall will create the chain
				  automatically. If the name of the
				  chain is followed by ":COUNT" then
				  a COUNT rule matching this rule
				  will automatically be added to
				  <chain>

	CHAIN	      - The name of the chain where the accounting
			rule is to be added. If empty or "-" then
			the "accounting" chain is assumed.

	SOURCE	      - Packet Source

			The name of an interface, an address (host or
			net) or an interface name followed by ":"
			and a host or net address. 

	DESTINATION   - Packet Destination

			Format the same as the SOURCE column.

	PROTOCOL	A protocol name (from /etc/protocols), a
			protocol number.

	DEST PORT	Destination Port number

			Service name from /etc/services or port
			number. May only be specified if the protocol
			is TCP or UDP (6 or 17). 

	SOURCE PORT	Source Port number

			Service name from /etc/services or port
			number. May only be specified if the protocol
			is TCP or UDP (6 or 17).

   In all columns except ACTION and CHAIN, the values "-","any" and
   "all" are treated as wild-cards.

   The accounting rules are evaluated in the Netfilter 'filter'
   table. This is the same environment where the 'rules' file rules are
   evaluated and in this environment, DNAT has already occurred in
   inbound packets and SNAT has not yet occurred on outbound ones.

   The accounting rules are placed in a chain called "accounting" and
   can thus be displayed using "shorewall show accounting".

   See http://shorewall.net/Accounting.html for examples.
 
8) Bridge interfaces (br[0-9]) may now be used in /etc/shorewall/maclist.					       

9) 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
   to create two rules; a DNAT- rule and an ACCEPT rule which can be
   rate-limited separately.

   To specify a rate limit, you can follow one of two approaches:

   a) You may follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with

	  < <rate>/<interval>[:<burst>] >

	  where

	  <rate> is the sustained rate per <interval>
	  <interval> is "sec" or "min"
	  <burst> is the largest burst accepted within an
	          <interval>. If not given, the default of 5 is
		  assumed.

      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 ).

   b) There is a new RATE LIMIT column at the far right of the
      file (beyond column 80). You may place the rate limit there in
      the format:

	  <rate>/<interval>[:<burst>]

	  where <rate>, <interval> and <burst> are as above.
   
   You may not place a rate limit in both the ACTION and RATE LIMIT
   columns.

   Let's take an example:

	 ACCEPT<2/sec:4>	net	dmz	tcp	80
   
   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
   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.

   Warning: 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
   zones covered by the rule.

10) Multiple chains may now be displayed in one "shorewall show"
    command (e.g., shorewall show INPUT FORWARD OUTPUT).

11) Output rules (those with $FW as the SOURCE) may now be limited to
    a set of local users and/or groups. See
    http://shorewall.net/UserSets.html for details.

12) The RPM has been modified so that it no longer conflicts with
    SuSE's bizarre kernel RPMs.