forked from extern/shorewall_code
c8dc7f1271
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2136 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
309 lines
11 KiB
Plaintext
Executable File
309 lines
11 KiB
Plaintext
Executable File
Shorewall 2.3.3
|
|
|
|
-----------------------------------------------------------------------
|
|
Problems corrected in version 2.3.2
|
|
|
|
None.
|
|
-----------------------------------------------------------------------
|
|
New Features in version 2.3.2
|
|
|
|
1) Shorewall 2.3.2 can now configure routing if your kernel and
|
|
iptables support the ROUTE target extension. This extension is
|
|
available in Patch-O-Matic-ng.
|
|
|
|
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.
|
|
|
|
2) Shorewall 2.3.2 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.
|
|
|
|
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 'trask' 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.
|
|
|
|
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 CONNTRACK target and conntrack match as well as extended
|
|
MARK support. It does NOT require the ROUTE target extension.
|
|
|
|
-----------------------------------------------------------------------
|
|
Problems corrected in version 2.3.1
|
|
|
|
1) A typo in the 'tunnel' script has been corrected (thanks to Patrik
|
|
Varmecký).
|
|
|
|
2) Previously, if "shorewall save" was done with SAVE_IPSETS=Yes then
|
|
Shorewall would fail fast start on reboot because the ipset modules
|
|
were not loaded.
|
|
|
|
-----------------------------------------------------------------------
|
|
New Features in version 2.3.0
|
|
|
|
1) 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.
|
|
|
|
2) 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.
|