holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity
84c11b287a
shorewall_code/Shorewall2/releasenotes.txt
teastep fc7ef23103 Mention 'no more LEAF packages' in the upgrade issues 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2217 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2005-06-02 17:55:06 +00:00

397 lines
15 KiB
Plaintext
Executable File
Raw Blame History

Shorewall 2.4.0-RC2
-----------------------------------------------------------------------
Problems Corrected since 2.4.0-RC1
1) The value 'detect' in the GATEWAY column of the providers file
is no longer restricted to P-T-P interfaces.
2) Previously "shorewall add" would terminate with an error if any of
the listed hosts were already in the specified zone. Now a warning
message is issued and an attempt is made to add the non-duplicate
hosts to the zone (Patch by Tuomo Soini).
-----------------------------------------------------------------------
Upgrade Issues when moving to 2.4.0
1) Shorewall now enforces the restriction that mark values used in
/etc/shorewall/tcrules are less than 256. If you are using mark
values >= 256, you must change your configuration before you
upgrade.
2) The value "ipp2p" is no longer accepted in the PROTO column of the
rules file. This support has never worked as intended and filtering
P2P applications this way is a bad idea to begin with (you should be
using a proxy).
3) LEAF/Bering packages for version 2.4.0 and later will not be
available from shorewall.net. See http://leaf.sf.net for the lastest
version of Shorewall for LEAF variants.
-----------------------------------------------------------------------
New Features in version 2.4.0
1) Shorewall 2.4.0 includes support for multiple internet interfaces to
different ISPs.
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.
Columns are:
NAME The provider name.
NUMBER The provider number -- a number between 1 and 15
MARK A FWMARK value used in your
/etc/shorewall/tcrules file to direct packets to
this provider.
DUPLICATE The name of an existing table to duplicate. May
be 'main' or the name of a previous provider.
INTERFACE The name of the network interface to the
provider. Must be listed in
/etc/shorewall/interfaces.
GATEWAY The IP address of the provider's gateway router.
If you enter "detect" here then Shorewall will
attempt to determine the gateway IP address
automatically.
OPTIONS A comma-separated list selected from the
following:
track If specified, connections FROM this interface are
to be tracked so that responses may be routed
back out this same interface.
You want specify 'track' if internet hosts will be
connecting to local servers through this
provider.
Because of limitations in the 'ip' utility and
policy routing, you may not use the SAVE or
RESTORE tcrules options or use connection
marking on any traffic to or from this
interface. For traffic control purposes, you
must mark packets in the FORWARD chain (or
better yet, use the CLASSIFY target).
balance The providers that have 'balance' specified will
get outbound traffic load-balanced among them. By
default, all interfaces with 'balance' specified
will have the same weight (1). You can change the
weight of the route out of the interface by
specifiying balance=<weight> where <weight> is
the desired route weight.
Example: You run squid in your DMZ on IP address
192.168.2.99. Your DMZ interface is eth2
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
Squid 1 1 - eth2 192.168.2.99 -
Use of this feature requires that your kernel and iptables
support CONNMARK target and conntrack match support. It does NOT
require the ROUTE target extension.
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" will
fail. You must patch your iptables using the patch at
http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff.
2) 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.
The syntax of the USER/GROUP column in the following files has been
extended:
/etc/shorewall/accounting
/etc/shorewall/rules
/etc/shorewall/tcrules
/usr/share/shorewall/action.template
To specify a command, prefix the command name with "+".
Examples:
+mozilla-bin #The program is named "mozilla-bin"
joe+mozilla-bin #The program is named "mozilla-bin" and
#is being run by user "joe"
joe:users+mozilla-bin #The program is named "mozilla-bin" and
#is being run by user "joe" with
#effective group "users".
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.
3) Support has been added for ipsets
(see http://people.netfilter.org/kadlec/ipset/).
In most places where a host or network address may be used, you may
also use the name of an ipset prefaced by "+".
Example: "+Mirrors"
The name of the set may be optionally followed by:
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.
Example: "+Mirrors[4]"
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.
Example: "+Mirrors[src,dst,src]"
Note that "+Mirrors[4]" used in the SOURCE column of the rules
file is equivalent to "+Mirrors[src,src,src,src]".
To generate a negative match, prefix the "+" with "!" as in
"!+Mirrors".
Example 1: Blacklist all hosts in an ipset named "blacklist"
/etc/shorewall/blacklist
#ADDRESS/SUBNET PROTOCOL PORT
+blacklist
Example 2: Allow SSH from all hosts in an ipset named "sshok:
/etc/shorewall/rules
#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT +sshok fw tcp 22
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.
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.
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.
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.
You can also associate ipset contents with Shorewall configuration
directories using the following command:
ipset -S > <config directory>/ipsets
Example:
ipset -S > /etc/shorewall/ipsets
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.
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).
Example /etc/shorewall/blacklist:
#ADDRESS/SUBNET PROTOCOL PORT
+Blacklist[src,dst]
+Blacklistnets[src,dst]
Create the blacklist ipsets using:
ipset -N Blacklist iphash
ipset -N Blacklistnets nethash
Add entries
ipset -A Blacklist 206.124.146.177
ipset -A Blacklistnets 206.124.146.0/24
To allow entries for individual ports
ipset -N SMTP portmap --from 1 --to 31
ipset -A SMTP 25
ipset -A Blacklist 206.124.146.177
ipset -B Blacklist 206.124.146.177 -b SMTP
Now only port 25 will be blocked from 206.124.146.177.
4) 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.
Routing is configured using the /etc/shorewall/routes file. Columns
in the file are as follows:
SOURCE Source of the packet. May be any of the
following:
- A host or network address
- A network interface name.
- The name of an ipset prefaced with "+"
- $FW (for packets originating on the firewall)
- A MAC address in Shorewall format
- A range of IP addresses (assuming that your
kernel and iptables support range match)
- A network interface name followed by ":"
and an address or address range.
DEST Destination of the packet. May be any of the
following:
- A host or network address
- A network interface name (determined from
routing table(s))
- The name of an ipset prefaced with "+"
- A network interface name followed by ":"
and an address or address range.
PROTO Protocol - Must be "tcp", "udp", "icmp",
"ipp2p", a number, or "all". "ipp2p" requires
ipp2p match support in your kernel and
iptables.
PORT(S) Destination Ports. A comma-separated list of
Port names (from /etc/services), port numbers
or port ranges; if the protocol is "icmp", this
column is interpreted as the destination
icmp-type(s).
If the protocol is ipp2p, this column is
interpreted as an ipp2p option without the
leading "--" (example "bit" for bit-torrent).
If no PORT is given, "ipp2p" is assumed.
This column is ignored if PROTOCOL = all but
must be entered if any of the following field
is supplied. In that case, it is suggested that
this field contain "-"
SOURCE PORT(S) (Optional) Source port(s). If omitted,
any source port is acceptable. Specified as a
comma-separated list of port names, port
numbers or port ranges.
TEST Defines a test on the existing packet or
connection mark.
The rule will match only if the test returns
true. Tests have the format
[!]<value>[/<mask>][:C]
Where:
! Inverts the test (not equal)
<value> Value of the packet or
connection mark.
<mask> A mask to be applied to the
mark before testing
:C Designates a connection
mark. If omitted, the packet
mark's value is tested.
INTERFACE The interface that the packet is to be routed
out of. If you do not specify this field then
you must place "-" in this column and enter an
IP address in the GATEWAY column.
GATEWAY The gateway that the packet is to be forewarded
through.
5) Crossbeam Support (Thanks to Juan Jesús Prieto and the folks at
eneotecnologia.com)
If Shorewall is running in a Crossbeam System
(www.crossbeamsystems.com) you need to activate this directive if
you don't want the CPM to think the system is down and send a reset
signal. Also Crossbeam has a backplane chassis that needs to be
configured in such a way that it accepts all traffic.
This change adds two new options in /etc/shorewall/shorewall.conf:
CROSSBEAM and CROSSBEAM_BACKBONE.
If CROSSBEAM=Yes, then during a Shorewall start, restart or clear
instead of setting the default policies to DROP and then activating
established connections, Shorewall will first set the default
policies to ACCEPT, activate established connections and then set
the default policies to DROP. After that, Shorewall starts
generating the rules as usual.
If CROSSBEAM=No, CROSSBEAM_BACKBONE is not used. If CROSSBEAM is set
to Yes, CROSSBEAM_BACKBONE indicates the device used by the
backbone. If not specified or if specified as empty (e.g.,
CROSSBEAM="") then CROSSBEAM=No is assumed.
6) 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.
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'.
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'.
7) This change was implemented by Lorenzo Martignoni. It provides two
new commands: "safe-start" and "safe-restart".
safe-start 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.
safe-restart 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.
These new commands require either that your /bin/sh supports the
"-t" option to the 'read' command or that you have /bin/bash
installed.
View Git Blame Copy Permalink