forked from extern/shorewall_code
a18c573868
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@738 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
295 lines
11 KiB
Plaintext
Executable File
295 lines
11 KiB
Plaintext
Executable File
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. This has been corrected so
|
|
that the existing route is replaced if it already exists.
|
|
|
|
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.
|
|
|