shorewall_code/Shorewall/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").

Migration Issues:

1) Once you have installed this version of Shorewall, you must 
   restart Shorewall before you may use the 'drop', 'reject', 'allow'
   or 'save' commands.

2) To maintain strict compatibility with previous versions, current
   uses of "shorewall drop" and "shorewall reject" should be replaced
   with "shorewall dropall" and "shorewall rejectall". 

New Features:

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

   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.

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 file has two sections.

   The first section of the file is optional and allows aggregation of
   counter chains into other counter chains. It does this by allowing
   you to create an accounting chain hierarchy.

   The second section of the file has the following columns:

	ACTION	      - What to do when a match is found.

				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 that is
					  to be jumped to. Shorewall
					  will create the chain
					  automatically if it was not
					  created by a CHAIN entry in
					  the first section of the
					  file. If the name of
					  the chain is followed by
					  ":DONE" then after control
					  returns from the named chain,
					  the packet will not be
					  matched against any of the
					  following accounting rules.

	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 the first, 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". It should
   be noted that where the ACTION is <chain>:DONE then the entry
   generates two rules in "accounting"; the first is a jump to the
   named chain and the second is a RETURN rule which causes the
   accounting chain to be exited.

   Examples:

	COUNT		eth0		eth1   # Count traffic going through the
					       # router from eth0 to eth1
	COUNT		eth0:206.124.146.177   # Count traffic from my
					       # server arriving on
					       # eth0
	DONE		eth0		eth1:192.168.1.24
					       # Count traffic entering
					       # eth0 and going to host
					       # 192.168.1.24 on
					       # eth1. Don't check for
					       # any more matches.
   Example using CHAIN:

        # This example shows how you can aggretate two counters. The
        # counters being aggregated are input and output counters on
        # the device 'ppp0'

	CHAIN		tunnel		       # Create a chain called 'tunnel'
	CHAIN		tunnelin	tunnel # Create a chain called
					       # 'tunnelin' with all
					       # traffic sent to
					       # 'tunnelin' being sent
					       # on to 'tunnel'
	CHAIN		tunnelout	tunnel # Create a chain called
					       # 'tunnelout' with all
					       # traffic sent to
					       # 'tunnelout' being sent
					       # on to 'tunnel'
					       # any more matches
	tunnelin	ppp0		       # send all traffic from
					       # ppp0 to the chain called
					       # 'tunnelin'
	tunnelout	any		ppp0   # send all traffic to 
					       # ppp0 to the chain called
					       # 'tunnelout'