forked from extern/shorewall_code
d55bcfca0b
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@711 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
298 lines
11 KiB
Plaintext
Executable File
298 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").
|
|
|
|
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. See
|
|
http://shorewall.net/Accounting.html for a description of this
|
|
section.
|
|
|
|
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'. The CHAIN declarations go in the first
|
|
# section of the /etc/shorewall/accounting file.
|
|
|
|
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'
|
|
|
|
|
|
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, 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 ).
|
|
|
|
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.
|
|
|
|
|
|
|