http://shorewall.net/pub/shorewall/Snapshots
ftp://shorewall.net/pub/shorewall/Snapshots
Release Notes are attached
Changes since last Snapshot:
a) The per-interface dynamic blacklisting chains are now displayed by
"shorewall monitor"
b) IP Traffic Accounting support has been added.
c) Rules may now be rate-limited.
d) Bridge interfaces (br[0-9]) may now appear in entries in the maclist
file.
-Tom
--
Tom Eastep \ Shorewall - iptables made easy
Shoreline, \ http://shorewall.net
Washington USA \ teastep@shorewall.net
-------------- next part --------------
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.