mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-21 23:23:13 +01:00
Shorewall-2.0.1
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1244 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
da2433f994
commit
e53e24b7e9
@ -1,74 +1,40 @@
|
||||
Changes since 1.4.10
|
||||
Changes since 2.0.0
|
||||
|
||||
1) Remove 'unclean' support.
|
||||
1) Eliminate Warning about Policy as rule when using actions.
|
||||
|
||||
2) Remove NAT_BEFORE_RULES.
|
||||
2) Add bridging Code.
|
||||
|
||||
3) Remove HAVEROUTE column from ProxyARP.
|
||||
3) Cleanup Warning elimination.
|
||||
|
||||
4) Change default for ALL INTERFACES in /etc/shorewall/nat.
|
||||
4) Add 'nobogons'
|
||||
|
||||
5) Rename the product to Shorewall2.
|
||||
5) Add 'netmap'
|
||||
|
||||
6) Remove common chain.
|
||||
6) Fix another <zone>_frwd problem.
|
||||
|
||||
7) Add default action mechanism.
|
||||
7) Add -x option to /sbin/shorewall.
|
||||
|
||||
8) Add USER/GROUP column to /etc/shorewall2/action.template.
|
||||
8) Implement Sean Mathews's fix fix Proxy ARP and IPSEC.
|
||||
|
||||
9) Get installer/uninstaller to work.
|
||||
9) Improve zone-definition checking.
|
||||
|
||||
10) Restore HAVEROUTE and add PERSISTENT column to the proxy arp file.
|
||||
10) Add additional options to hosts file
|
||||
|
||||
11) Install correct init script on Debian.
|
||||
11) Replace 'subnet' with 'network' in the code
|
||||
|
||||
12) Get the attention of 'logunclean' and 'dropunclean' users.
|
||||
12) Fix item 10 above :-(
|
||||
|
||||
13) Replace all instances of `...` with $(...) for readability.
|
||||
13) Replace good code with crap to satisfy 'ash'.
|
||||
|
||||
14) Add action.AllowSNMP
|
||||
14) Fix if_match to only do wild-card matches on patterns ending in
|
||||
"+".
|
||||
|
||||
15) Move some code from firewall to functions
|
||||
15) Tighten edits on bridge port names.
|
||||
|
||||
16) Removed the DropBcast and DropNonSyn actions and replaced them with
|
||||
builtin actions dropBcast and dropNonSyn.
|
||||
16) Make 'routeback' on interfaces work again.
|
||||
|
||||
17) Make "trace" a synonym for "debug"
|
||||
17) Reduce useless intra-zone rules on bridges.
|
||||
|
||||
18) Add the ":noah" option to IPSEC tunnels.
|
||||
18) Make 'routeback' on hosts work again.
|
||||
|
||||
19) Added a comment to the rules file to aid users who are terminally stupid.
|
||||
|
||||
20) Only create the action chains that are actually used.
|
||||
|
||||
21) Move actions.std and action.* files to /usr/share/shorewall.
|
||||
|
||||
22) Added DISABLE_IPV6 option.
|
||||
|
||||
23) Allow rate limiting on CONTINUE and REJECT.
|
||||
|
||||
24) Move rfc1918 to /usr/share/shorewall
|
||||
|
||||
25) Make detectnets and routeback play nice together.
|
||||
|
||||
26) Avoid superfluous --state NEW tests.
|
||||
|
||||
27) Allow backrouting of 'routestopped' devices.
|
||||
|
||||
28) Fix the help file.
|
||||
|
||||
29) Correct handling of !z1,z2,... in a DNAT/REDIRECT rule.
|
||||
|
||||
30) Remove fw->fw policy.
|
||||
|
||||
31) Issue clearer message if ip6tables not installed.
|
||||
|
||||
32) Make 'CONTINUE' rules work again.
|
||||
|
||||
33) Correct a comment in the rules file. Update for 2.0.0 final release.
|
||||
|
||||
34) Eliminate Warning about Policy as rule when using actions.
|
||||
|
||||
35) Implement Sean Mathews's fix for Proxy ARP/IPSEC.
|
||||
|
||||
36) Fix default value of ALL INTERFACES in /etc/shorewall/nat.
|
||||
19) Fix display of ICMP packets.
|
||||
|
||||
@ -28,7 +28,7 @@
|
||||
# shown below. Simply run this script to revert to your prior version of
|
||||
# Shoreline Firewall.
|
||||
|
||||
VERSION=2.0.0b
|
||||
VERSION=2.0.1
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
@ -91,6 +91,8 @@ restore_file /etc/shorewall/rules
|
||||
|
||||
restore_file /etc/shorewall/nat
|
||||
|
||||
restore_file /etc/shorewall/netmap
|
||||
|
||||
restore_file /etc/shorewall/params
|
||||
|
||||
restore_file /etc/shorewall/proxyarp
|
||||
@ -116,6 +118,8 @@ restore_file /etc/shorewall/whitelist
|
||||
restore_file /etc/shorewall/rfc1918
|
||||
restore_file /usr/share/shorewall/rfc1918
|
||||
|
||||
restore_file /usr/share/shorewall/bogons
|
||||
|
||||
restore_file /etc/shorewall/init
|
||||
|
||||
restore_file /etc/shorewall/start
|
||||
|
||||
670
STABLE2/firewall
670
STABLE2/firewall
File diff suppressed because it is too large
Load Diff
@ -470,9 +470,9 @@ broadcastaddress() {
|
||||
}
|
||||
|
||||
#
|
||||
# Test for subnet membership
|
||||
# Test for network membership
|
||||
#
|
||||
in_subnet() # $1 = IP address, $2 = CIDR network
|
||||
in_network() # $1 = IP address, $2 = CIDR network
|
||||
{
|
||||
local netmask=$(ip_netmask $2)
|
||||
|
||||
@ -502,11 +502,11 @@ ip_vlsm() {
|
||||
|
||||
#
|
||||
# Chain name base for an interface -- replace all periods with underscores in the passed name.
|
||||
# The result is echoed (less "+" and anything following).
|
||||
# The result is echoed (less trailing "+").
|
||||
#
|
||||
chain_base() #$1 = interface
|
||||
{
|
||||
local c=${1%%+*}
|
||||
local c=${1%%+}
|
||||
|
||||
while true; do
|
||||
case $c in
|
||||
@ -524,29 +524,25 @@ chain_base() #$1 = interface
|
||||
done
|
||||
}
|
||||
|
||||
#
|
||||
# Remove trailing digits from a name
|
||||
#
|
||||
strip_trailing_digits() {
|
||||
echo $1 | sed s'/[0-9].*$//'
|
||||
}
|
||||
|
||||
#
|
||||
# Loosly Match the name of an interface
|
||||
#
|
||||
|
||||
if_match() # $1 = Name in interfaces file - may end in "+"
|
||||
# $2 = Name from routing table
|
||||
# $2 = Full interface name - may also end in "+"
|
||||
{
|
||||
local if_file=$1
|
||||
local rt_table=$2
|
||||
|
||||
case $if_file in
|
||||
local pattern=${1%+}
|
||||
|
||||
case $1 in
|
||||
*+)
|
||||
test "$(strip_trailing_digits $rt_table)" = "${if_file%+}"
|
||||
#
|
||||
# Can't use ${2:0:${#pattern}} because ash and dash don't support that flavor of
|
||||
# variable expansion :-(
|
||||
#
|
||||
test "x$(echo $2 | cut -b -${#pattern} )" = "x${pattern}"
|
||||
;;
|
||||
*)
|
||||
test "$rt_table" = "$if_file"
|
||||
test "x$1" = "x$2"
|
||||
;;
|
||||
esac
|
||||
}
|
||||
@ -571,7 +567,7 @@ find_rt_interface() {
|
||||
ip route ls | while read addr rest; do
|
||||
case $addr in
|
||||
*/*)
|
||||
in_subnet ${1%/*} $addr && echo $(find_device $rest)
|
||||
in_network ${1%/*} $addr && echo $(find_device $rest)
|
||||
;;
|
||||
default)
|
||||
;;
|
||||
|
||||
27
STABLE2/help
27
STABLE2/help
@ -147,8 +147,13 @@ logwatch)
|
||||
|
||||
monitor)
|
||||
echo "monitor: monitor [<refresh_interval>]
|
||||
|
||||
shorewall [-x] monitor [<refresh_interval>]
|
||||
|
||||
Continuously display the firewall status, last 20 log entries and nat.
|
||||
When the log entry display changes, an audible alarm is sounded."
|
||||
When the log entry display changes, an audible alarm is sounded.
|
||||
|
||||
When -x is given, that option is also passed to iptables to display actual packet and byte counts."
|
||||
;;
|
||||
|
||||
refresh)
|
||||
@ -185,14 +190,15 @@ save)
|
||||
;;
|
||||
|
||||
show)
|
||||
echo "show: show [<chain> [ <chain> ...] |classifiers|connections|log|nat|tc|tos]
|
||||
shorewall show <chain> [ <chain> ... ] - produce a verbose report about the IPtable chain(s).
|
||||
echo "show: show [ <chain> [ <chain> ...] |classifiers|connections|log|nat|tc|tos]
|
||||
|
||||
shorewall [-x] show <chain> [ <chain> ... ] - produce a verbose report about the IPtable chain(s).
|
||||
(iptables -L chain -n -v)
|
||||
|
||||
shorewall show nat - produce a verbose report about the nat table.
|
||||
shorewall [-x] show nat - produce a verbose report about the nat table.
|
||||
(iptables -t nat -L -n -v)
|
||||
|
||||
shorewall show tos - produce a verbose report about the mangle table.
|
||||
shorewall [-x] show tos - produce a verbose report about the mangle table.
|
||||
(iptables -t mangle -L -n -v)
|
||||
|
||||
shorewall show log - display the last 20 packet log entries.
|
||||
@ -201,7 +207,9 @@ show)
|
||||
being tracked by the firewall.
|
||||
|
||||
shorewall show tc - displays information about the traffic
|
||||
control/shaping configuration."
|
||||
control/shaping configuration.
|
||||
|
||||
When -x is given, that option is also passed to iptables to display actual packet and byte counts."
|
||||
;;
|
||||
|
||||
start)
|
||||
@ -221,9 +229,14 @@ stop)
|
||||
|
||||
status)
|
||||
echo "status: status
|
||||
|
||||
shorewall [-x] status
|
||||
|
||||
Produce a verbose report about the firewall.
|
||||
|
||||
(iptables -L -n -v)"
|
||||
(iptables -L -n -)
|
||||
|
||||
When -x is given, that option is also passed to iptables to display actual packet and byte counts."
|
||||
;;
|
||||
|
||||
trace)
|
||||
|
||||
@ -5,28 +5,39 @@
|
||||
# ONE ZONE CONNECTED THROUGH A SINGLE INTERFACE.
|
||||
#
|
||||
# IF YOU DON'T HAVE THAT SITUATION THEN DON'T TOUCH THIS FILE.
|
||||
#
|
||||
#------------------------------------------------------------------------------
|
||||
# IF YOU HAVE AN ENTRY FOR A ZONE AND INTERFACE IN
|
||||
# /etc/shorewall/interfaces THEN DO NOT ADD ANY ENTRIES FOR THAT
|
||||
# ZONE AND INTERFACE IN THIS FILE.
|
||||
#------------------------------------------------------------------------------
|
||||
# This file is used to define zones in terms of subnets and/or
|
||||
# individual IP addresses. Most simple setups don't need to
|
||||
# (should not) place anything in this file.
|
||||
#
|
||||
# ZONE - The name of a zone defined in /etc/shorewall/zones
|
||||
#
|
||||
# HOST(S) - The name of an interface followed by a colon (":") and
|
||||
# HOST(S) - The name of an interface defined in the
|
||||
# /etc/shorewall/interfaces file followed by a colon (":") and
|
||||
# a comma-separated list whose elements are either:
|
||||
#
|
||||
# a) The IP address of a host
|
||||
# b) A subnetwork in the form
|
||||
# <subnet-address>/<mask width>
|
||||
#
|
||||
# The interface must be defined in the
|
||||
# /etc/shorewall/interfaces file.
|
||||
# c) A physical port name; only allowed when the
|
||||
# interface names a bridge created by the
|
||||
# brctl addbr command. This port must not
|
||||
# be defined in /etc/shorewall/interfaces and may
|
||||
# optionally followed by a colon (":") and a
|
||||
# host or network IP.
|
||||
# See http://www.shorewall.net/Bridge.html for details.
|
||||
#
|
||||
# Examples:
|
||||
#
|
||||
# eth1:192.168.1.3
|
||||
# eth2:192.168.2.0/24
|
||||
# eth3:192.168.2.0/24,192.168.3.1
|
||||
# br0:eth4
|
||||
# br0:eth0:192.168.1.16/28
|
||||
#
|
||||
# OPTIONS - A comma-separated list of options. Currently-defined
|
||||
# options are:
|
||||
@ -47,6 +58,66 @@
|
||||
# to send requests originating from this
|
||||
# group to a server in the group.
|
||||
#
|
||||
# norfc1918 - This option only makes sense for ports
|
||||
# on a bridge.
|
||||
#
|
||||
# The port should not accept
|
||||
# any packets whose source is in one
|
||||
# of the ranges reserved by RFC 1918
|
||||
# (i.e., private or "non-routable"
|
||||
# addresses. If packet mangling or
|
||||
# connection-tracking match is enabled in
|
||||
# your kernel, packets whose destination
|
||||
# addresses are reserved by RFC 1918 are
|
||||
# also rejected.
|
||||
#
|
||||
# nobogons - This option only makes sense for ports
|
||||
# on a bridge.
|
||||
#
|
||||
# This port should not accept
|
||||
# any packets whose source is in one
|
||||
# of the ranges reserved by IANA (this
|
||||
# option does not cover those ranges
|
||||
# reserved by RFC 1918 -- see
|
||||
# 'norfc1918' above).
|
||||
#
|
||||
# blacklist - This option only makes sense for ports
|
||||
# on a bridge.
|
||||
#
|
||||
# Check packets arriving on this port
|
||||
# against the /etc/shorewall/blacklist
|
||||
# file.
|
||||
#
|
||||
# tcpflags - Packets arriving from these hosts are
|
||||
# checked for certain illegal combinations
|
||||
# of TCP flags. Packets found to have
|
||||
# such a combination of flags are handled
|
||||
# according to the setting of
|
||||
# TCP_FLAGS_DISPOSITION after having been
|
||||
# logged according to the setting of
|
||||
# TCP_FLAGS_LOG_LEVEL.
|
||||
#
|
||||
# nosmurfs - This option only makes sense for ports
|
||||
# on a bridge.
|
||||
#
|
||||
# Filter packets for smurfs
|
||||
# (packets with a broadcast
|
||||
# address as the source).
|
||||
#
|
||||
# Smurfs will be optionally logged based
|
||||
# on the setting of SMURF_LOG_LEVEL in
|
||||
# shorewall.conf. After logging, the
|
||||
# packets are dropped.
|
||||
#
|
||||
# newnotsyn - TCP packets that don't have the SYN
|
||||
# flag set and which are not part of an
|
||||
# established connection will be accepted
|
||||
# from these hosts, even if
|
||||
# NEWNOTSYN=No has been specified in
|
||||
# /etc/shorewall/shorewall.conf.
|
||||
#
|
||||
# This option has no effect if
|
||||
# NEWNOTSYN=Yes.
|
||||
#
|
||||
#ZONE HOST(S) OPTIONS
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA
|
||||
#
|
||||
|
||||
VERSION=2.0.0b
|
||||
VERSION=2.0.1
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
@ -270,6 +270,16 @@ else
|
||||
echo "NAT file installed as ${PREFIX}/etc/shorewall/nat"
|
||||
fi
|
||||
#
|
||||
# Install the NETMAP file
|
||||
#
|
||||
if [ -f ${PREFIX}/etc/shorewall/netmap ]; then
|
||||
backup_file /etc/shorewall/netmap
|
||||
else
|
||||
run_install -o $OWNER -g $GROUP -m 0600 netmap ${PREFIX}/etc/shorewall/netmap
|
||||
echo
|
||||
echo "NETMAP file installed as ${PREFIX}/etc/shorewall/netmap"
|
||||
fi
|
||||
#
|
||||
# Install the Parameters file
|
||||
#
|
||||
if [ -f ${PREFIX}/etc/shorewall/params ]; then
|
||||
@ -384,6 +394,12 @@ install_file_with_backup rfc1918 ${PREFIX}/usr/share/shorewall/rfc1918 0600
|
||||
echo
|
||||
echo "RFC 1918 file installed as ${PREFIX}/etc/shorewall/rfc1918"
|
||||
#
|
||||
# Install the bogons file
|
||||
#
|
||||
install_file_with_backup bogons ${PREFIX}/usr/share/shorewall/bogons 0600
|
||||
echo
|
||||
echo "Bogon file installed as ${PREFIX}/etc/shorewall/bogons"
|
||||
#
|
||||
# Install the init file
|
||||
#
|
||||
if [ -f ${PREFIX}/etc/shorewall/init ]; then
|
||||
|
||||
@ -46,31 +46,51 @@
|
||||
# OPTIONS A comma-separated list of options including the
|
||||
# following:
|
||||
#
|
||||
# dhcp - interface is managed by DHCP or used by
|
||||
# a DHCP server running on the firewall or
|
||||
# you have a static IP but are on a LAN
|
||||
# segment with lots of Laptop DHCP clients.
|
||||
# dhcp - Specify this option when any of
|
||||
# the following are true:
|
||||
# 1. the interface gets its IP address
|
||||
# via DHCP
|
||||
# 2. the interface is used by
|
||||
# a DHCP server running on the firewall
|
||||
# 3. you have a static IP but are on a LAN
|
||||
# segment with lots of Laptop DHCP
|
||||
# clients.
|
||||
# 4. the interface is a bridge with
|
||||
# a DHCP server on one port and DHCP
|
||||
# clients on another port.
|
||||
#
|
||||
# norfc1918 - This interface should not receive
|
||||
# any packets whose source is in one
|
||||
# of the ranges reserved by RFC 1918
|
||||
# (i.e., private or "non-routable"
|
||||
# addresses. If packet mangling is
|
||||
# enabled in shorewall.conf, packets
|
||||
# whose destination addresses are
|
||||
# reserved by RFC 1918 are also rejected.
|
||||
# addresses. If packet mangling or
|
||||
# connection-tracking match is enabled in
|
||||
# your kernel, packets whose destination
|
||||
# addresses are reserved by RFC 1918 are
|
||||
# also rejected.
|
||||
#
|
||||
# nobogons - This interface should not receive
|
||||
# any packets whose source is in one
|
||||
# of the ranges reserved by IANA (this
|
||||
# option does not cover those ranges
|
||||
# reserved by RFC 1918 -- see above).
|
||||
#
|
||||
# routefilter - turn on kernel route filtering for this
|
||||
# interface (anti-spoofing measure). This
|
||||
# option can also be enabled globally in
|
||||
# the /etc/shorewall/shorewall.conf file.
|
||||
#
|
||||
# . . blacklist - Check packets arriving on this interface
|
||||
# against the /etc/shorewall/blacklist
|
||||
# file.
|
||||
#
|
||||
# maclist - Connection requests from this interface
|
||||
# are compared against the contents of
|
||||
# /etc/shorewall/maclist. If this option
|
||||
# is specified, the interface must be
|
||||
# an ethernet NIC and must be up before
|
||||
# Shorewall is started.
|
||||
#
|
||||
# tcpflags - Packets arriving on this interface are
|
||||
# checked for certain illegal combinations
|
||||
# of TCP flags. Packets found to have
|
||||
@ -79,6 +99,7 @@
|
||||
# TCP_FLAGS_DISPOSITION after having been
|
||||
# logged according to the setting of
|
||||
# TCP_FLAGS_LOG_LEVEL.
|
||||
#
|
||||
# proxyarp -
|
||||
# Sets
|
||||
# /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
|
||||
@ -127,7 +148,7 @@
|
||||
# hosts routed through the interface.
|
||||
#
|
||||
# WARNING: DO NOT SET THE detectnets OPTION ON YOUR
|
||||
# INTERNET INTERFACE!
|
||||
# INTERNET INTERFACE.
|
||||
#
|
||||
# The order in which you list the options is not
|
||||
# significant but the list should have no embedded white
|
||||
|
||||
@ -1,237 +1,100 @@
|
||||
Shorewall 2.0.0b
|
||||
Shorewall 2.0.1
|
||||
|
||||
----------------------------------------------------------------------
|
||||
Problems Corrected since 1.4.10
|
||||
|
||||
1) A blank USER/GROUP column in /etc/shorewall/tcrules no longer causes
|
||||
a [re]start error.
|
||||
|
||||
2) The 'fgrep' utility is no longer required (caused startup problems
|
||||
on LEAF/Bering).
|
||||
|
||||
3) The "shorewall add" command no longer inserts rules before checking
|
||||
of the blacklist.
|
||||
|
||||
4) The 'detectnets' and 'routeback' options may now be used together
|
||||
with the intended effect.
|
||||
|
||||
5) The following syntax previously produced an error:
|
||||
|
||||
DNAT z1!z2,z3 z4...
|
||||
|
||||
Problems Corrected since RC2
|
||||
|
||||
1) CONTINUE rules now work again.
|
||||
|
||||
2) A comment in the rules file has been corrected.
|
||||
|
||||
Problems Corrected since 2.0.0
|
||||
|
||||
1) Using actions in the manner recommended in the documentation
|
||||
results in a Warning that the rule is a policy.
|
||||
|
||||
Problems Corrected since 2.0.0a
|
||||
2) When a zone on a single interface is defined using
|
||||
/etc/shorewall/hosts, superfluous rules are generated in the
|
||||
<zone>_frwd chain.
|
||||
|
||||
1) Thanks to Sean Mathews, a long-time problem with Proxy ARP and IPSEC
|
||||
has been corrected.
|
||||
3) Thanks to Sean Mathews, a long-standing problem with Proxy ARP and
|
||||
IPSEC has been corrected. Thanks Sean!!!
|
||||
|
||||
2) The Default value for ALL INTERFACES in the /etc/shorewall/nat file
|
||||
is supposed to be 'no' but it remained 'yes' as in 1.4.
|
||||
4) The "shorewall show log" and "shorewall logwatch" commands
|
||||
incorrectly displayed type 3 ICMP packets.
|
||||
|
||||
-----------------------------------------------------------------------
|
||||
Issues when migrating from Shorewall 1.4.x to Shorewall 2.0.0:
|
||||
Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:
|
||||
|
||||
1) The 'dropunclean' and 'logunclean' interface options are no longer
|
||||
supported. If either option is specified in
|
||||
/etc/shorewall/interfaces, an threatening message will be
|
||||
generated.
|
||||
1) The function of 'norfc1918' is now split between that option and a
|
||||
new 'nobogons' option.
|
||||
|
||||
2) The NAT_BEFORE_RULES option has been removed from
|
||||
shorewall.conf. The behavior of Shorewall is as if
|
||||
NAT_BEFORE_RULES=No had been specified. In other words, DNAT rules
|
||||
now always take precidence over one-to-one NAT specifications.
|
||||
The rfc1918 file released with Shorewall now contains entries for
|
||||
only those three address ranges reserved by RFC 1918. A 'nobogons'
|
||||
interface option has been added which handles bogon source
|
||||
addresses (those which are reserved by the IANA, those reserved for
|
||||
DHCP auto-configuration and the class C test-net reserved for
|
||||
testing and documentation examples). This will allow users to
|
||||
perform RFC 1918 filtering without having to deal with out
|
||||
of date data from IANA. Those who are willing to update their
|
||||
/usr/share/shorewall/bogons file regularly can specify the
|
||||
'nobogons' option in addition to 'norfc1918'.
|
||||
|
||||
3) The default value for the ALL INTERFACES column in
|
||||
/etc/shorewall/nat has changed. In Shorewall 1.*, if the column was
|
||||
left empty, a value of "Yes" was assumed. This has been changed so
|
||||
that a value of "No" is now assumed.
|
||||
|
||||
4) The following files don't exist in Shorewall 2.0:
|
||||
|
||||
/etc/shorewall/common.def
|
||||
/etc/shorewall/common
|
||||
/etc/shorewall/icmpdef
|
||||
/etc/shorewall/action.template (Moved to /usr/share/shorewall)
|
||||
/etc/shorewall/rfc1918 (Moved to /usr/share/shorewall).
|
||||
|
||||
The /etc/shorewall/action file now allows an action to be
|
||||
designated as the "common" action for a particular policy type by
|
||||
following the action name with ":" and the policy (DROP, REJECT or
|
||||
ACCEPT).
|
||||
|
||||
The file /usr/share/shorewall/actions.std has been added to define those
|
||||
actions that are released as part of Shorewall. In that file are
|
||||
two actions as follows:
|
||||
|
||||
Drop:DROP
|
||||
Reject:REJECT
|
||||
|
||||
The "Drop" action is the common action for DROP policies while the
|
||||
"Reject" action is the default action for "REJECT" policies. These
|
||||
actions will be performed on packets prior to applying the DROP or
|
||||
REJECT policy respectively. In the first release, the difference
|
||||
between "Reject" and "Drop" is that "Reject" REJECTs SMB traffic
|
||||
while "Drop" silently drops such traffic.
|
||||
|
||||
As described above, Shorewall allows a common action for ACCEPT
|
||||
policies but does not specify such an action in the default
|
||||
configuration.
|
||||
|
||||
If for some reason, you don't wish to have a common DROP or REJECT
|
||||
action, just include :DROP or :REJECT respectively in your
|
||||
/etc/shorewall/actions file.
|
||||
|
||||
The file /usr/share/shorewall/actions.std catalogs the standard
|
||||
actions and is processed prior to /etc/shorewall/actions. This
|
||||
causes a large number of actions to be defined. The files which
|
||||
define these aactions are also located in /usr/share/shorewall as
|
||||
is the he action template file (action.template).
|
||||
|
||||
In the initial release, the following actions are defined:
|
||||
|
||||
dropBcast #Silently Drops Broadcast Traffic
|
||||
dropNonSyn #Silently Drop Non-syn TCP packets
|
||||
|
||||
DropSMB #Silently Drops Microsoft SMB Traffic
|
||||
RejectSMB #Silently Reject Microsoft SMB Traffic
|
||||
DropUPnP #Silently Drop UPnP Probes
|
||||
RejectAuth #Silently Reject Auth
|
||||
DropPing #Silently Drop Ping
|
||||
DropDNSrep #Silently Drop DNS Replies
|
||||
|
||||
AllowPing #Accept Ping
|
||||
AllowFTP #Accept FTP
|
||||
AllowDNS #Accept DNS
|
||||
AllowSSH #Accept SSH
|
||||
AllowWeb #Allow Web Browsing
|
||||
AllowSMB #Allow MS Networking
|
||||
AllowAuth #Allow Auth (identd)
|
||||
AllowSMTP #Allow SMTP (Email)
|
||||
AllowPOP3 #Allow reading mail via POP3
|
||||
AllowIMAP #Allow reading mail via IMAP
|
||||
AllowTelnet #Allow Telnet Access (not recommended for use over the
|
||||
#Internet)
|
||||
AllowVNC #Allow VNC, Displays 0-9
|
||||
AllowVNCL #Allow access to VNC viewer in listen mode
|
||||
AllowNTP #Allow Network Time Protocol (ntpd)
|
||||
AllowRdate #Allow remote time (rdate).
|
||||
AllowNNTP #Allow network news (Usenet).
|
||||
AllowTrcrt #Allows Traceroute (20 hops)
|
||||
AllowSNMP #Allows SNMP (including traps)
|
||||
AllowPCA #Allows PCAnywhere (tm).
|
||||
|
||||
Drop:DROP #Common rules for DROP policy
|
||||
Reject:REJECT #Common Action for Reject policy
|
||||
|
||||
These actions may be used in the ACTION column of the rules
|
||||
column. So for example, to allow FTP from your loc zone to your firewall,
|
||||
you would place this rule in /etc/shorewall/rules:
|
||||
|
||||
#ACTION SOURCE DEST
|
||||
AllowFTP loc fw
|
||||
|
||||
if you want to redefine any of the Shorewall-defined actions,
|
||||
simply copy the appropriate action file from /usr/share/shorewall
|
||||
to /etc/shorewall and modify the copy as desired. Your modified
|
||||
copy will be used rather than the original one in
|
||||
/usr/share/shorewall.
|
||||
|
||||
Note: The 'dropBcast' and 'dropNonSyn' actions are built into
|
||||
Shorewall and may not be changed.
|
||||
|
||||
Beginning with version 2.0.0-Beta2, Shorewall will only create a
|
||||
chain for those actions that are actually used.
|
||||
|
||||
5) The /etc/shorewall directory no longer contains a 'users' file or a
|
||||
'usersets' file. Similar functionality is now available using
|
||||
user-defined actions.
|
||||
|
||||
Now, action files created by copying
|
||||
/usr/share/shorewall/action.template may now specify a USER and or
|
||||
GROUP name/id in the final column just like in the rules file (see
|
||||
below). It is thus possible to create actions that control traffic
|
||||
from a list of users and/or groups.
|
||||
|
||||
The last column in /etc/shorewall/rules is now labeled USER/GROUP
|
||||
and may contain:
|
||||
|
||||
[!]<user number>[:]
|
||||
[!]<user name>[:]
|
||||
[!]:<group number>
|
||||
[!]:<group name>
|
||||
[!]<user number>:<group number>
|
||||
[!]<user number>:<group name>
|
||||
[!]<user name>:<group number>
|
||||
[!]<user name>:<group name>
|
||||
|
||||
6) It is no longer possible to specify rate limiting in the ACTION
|
||||
column of /etc/shorewall/rules -- you must use the RATE LIMIT
|
||||
column.
|
||||
|
||||
7) Depending on which method you use to upgrade, if you have your own
|
||||
version of /etc/shorewall/rfc1918, you may have to take special
|
||||
action to restore it after the upgrade. Look for
|
||||
/etc/shorewall/rfc1918*, locate the proper file and rename it back
|
||||
to /etc/shorewall/rfc1918. The contents of that file will supercede
|
||||
the contents of /usr/share/shorewall/rfc1918.
|
||||
The level at which bogon packets are logged is specified in the new
|
||||
BOGON_LOG_LEVEL variable in shorewall.conf. If that option is not
|
||||
specified or is specified as empty (e.g, BOGON_LOG_LEVEL="") then
|
||||
bogon packets whose TARGET is 'logdrop' in
|
||||
/usr/share/shorewall/bogons are logged at the 'info' level.
|
||||
|
||||
New Features:
|
||||
|
||||
1) The INCLUDE directive now allows absolute file names.
|
||||
1) Support for Bridging Firewalls has been added. For details, see
|
||||
|
||||
2) A 'nosmurfs' interface option has been added to
|
||||
/etc/shorewall/interfaces. When specified for an interface, this
|
||||
option causes smurfs (packets with a broadcast address as their
|
||||
source) to be dropped and optionally logged (based on the setting of
|
||||
a new SMURF_LOG_LEVEL option in shorewall.conf).
|
||||
http://shorewall.net/bridge.html
|
||||
|
||||
3) fw->fw traffic may now be controlled by Shorewall. There is no need
|
||||
to define the loopback interface in /etc/shorewall/interfaces; you
|
||||
simply add a fw->fw policy and fw->fw rules. If you have neither a
|
||||
fw->fw policy nor fw->fw rules, all fw->fw traffic is allowed.
|
||||
2) Support for NETMAP has been added. NETMAP allows NAT to be defined
|
||||
between two network:
|
||||
|
||||
4) There is a new PERSISTENT column in the proxyarp file. A value of
|
||||
"Yes" in this column means that the route added by Shorewall for
|
||||
this host will remain after a "shorewall stop" or "shorewall clear".
|
||||
a.b.c.1 -> x.y.z.1
|
||||
a.b.c.2 -> x.y.z.2
|
||||
a.b.c.3 -> x.y.z.3
|
||||
...
|
||||
|
||||
5) "trace" is now a synonym for "debug" in /sbin/shorewall commands.
|
||||
So to trace the "start" command, you could enter:
|
||||
http://shorewall.net/netmap.html
|
||||
|
||||
shorewall trace start 2> /tmp/trace
|
||||
3) The /sbin/shorewall program now accepts a "-x" option to cause
|
||||
iptables to print out the actual packet and byte counts rather than
|
||||
abbreviated counts such as "13MB".
|
||||
|
||||
The trace information would be written to the file /tmp/trace.
|
||||
Commands affected by this are:
|
||||
|
||||
6) When defining an ipsec tunnel in /etc/shorewall/tunnels, if you
|
||||
follow the tunnel type ("ipsec" or "ipsecnet") with ":noah"
|
||||
(e.g., "ipsec:noah"), then Shorewall will only create rules for
|
||||
ESP (protocol 50) and will not create rules for AH (protocol 51).
|
||||
shorewall -x show [ <chain>[ <chain> ...] ]
|
||||
shorewall -x show tos|mangle
|
||||
shorewall -x show nat
|
||||
shorewall -x status
|
||||
shorewall -x monitor [ <interval> ]
|
||||
|
||||
7) A new DISABLE_IPV6 option has been added to shorewall.conf. When
|
||||
this option is set to "Yes", Shorewall will set the policy for the
|
||||
IPv6 INPUT, OUTPUT and FORWARD chains to DROP during "shorewall
|
||||
[re]start" and "shorewall stop". Regardless of the setting of this
|
||||
variable, "shorewall clear" will silently attempt to set these
|
||||
policies to ACCEPT.
|
||||
4) Shorewall now traps two common zone definition errors:
|
||||
|
||||
If this option is not set in your existing shorewall.conf then a
|
||||
setting of DISABLE_IPV6=No is assumed in which case, Shorewall will
|
||||
not touch any IPv6 settings except during "shorewall clear".
|
||||
- Including the firewall zone in a /etc/shorewall/hosts record.
|
||||
- Defining an interface for a zone in both /etc/shorewall/interfaces
|
||||
and /etc/shorewall/hosts.
|
||||
|
||||
8) The CONTINUE target is now available in action definitions. CONTINUE
|
||||
terminates processing of the current action and returns to the point
|
||||
where that action was invoked.
|
||||
In the second case, the following will appear during "shorewall
|
||||
[re]start" or "shorewall check":
|
||||
|
||||
Determining Hosts in Zones...
|
||||
...
|
||||
Error: Invalid zone definition for zone <name of zone>
|
||||
Terminated
|
||||
|
||||
5) To support bridging, the following options have been added to
|
||||
entries in /etc/shorewall/hosts:
|
||||
|
||||
norfc1918
|
||||
nobogons
|
||||
blacklist
|
||||
tcpflags
|
||||
nosmurfs
|
||||
newnotsyn
|
||||
|
||||
|
||||
With the exception of 'newnotsyn', these options are only
|
||||
useful when the entry refers to a bridge port.
|
||||
|
||||
Example:
|
||||
|
||||
#ZONE HOST(S) OPTIONS
|
||||
net br0:eth0 norfc1918,nobogons,blacklist,tcpflags,nosmurfs
|
||||
|
||||
@ -5,9 +5,10 @@
|
||||
#
|
||||
# Lists the subnetworks that are blocked by the 'norfc1918' interface option.
|
||||
#
|
||||
# The default list includes those IP addresses listed in RFC 1918, those listed
|
||||
# as 'reserved' by the IANA, the DHCP Autoconfig class B, and the class C
|
||||
# reserved for use in documentation and examples.
|
||||
# The default list includes those IP addresses listed in RFC 1918.
|
||||
#
|
||||
# DO NOT MODIFY THIS FILE. IF YOU NEED TO MAKE CHANGES, COPY THE FILE
|
||||
# TO /etc/shorewall AND MODIFY THE COPY.
|
||||
#
|
||||
# Columns are:
|
||||
#
|
||||
@ -19,45 +20,7 @@
|
||||
#
|
||||
###############################################################################
|
||||
#SUBNET TARGET
|
||||
255.255.255.255 RETURN # We need to allow limited broadcast
|
||||
169.254.0.0/16 DROP # DHCP autoconfig
|
||||
172.16.0.0/12 logdrop # RFC 1918
|
||||
192.0.2.0/24 logdrop # Example addresses (RFC 3330)
|
||||
192.168.0.0/16 logdrop # RFC 1918
|
||||
#
|
||||
# The following are generated with the help of the Python program found at:
|
||||
#
|
||||
# http://www.shorewall.net/pub/shorewall/contrib/iana_reserved/
|
||||
#
|
||||
# The program was contributed by Andy Wiggin
|
||||
#
|
||||
0.0.0.0/7 logdrop # Reserved
|
||||
2.0.0.0/8 logdrop # Reserved
|
||||
5.0.0.0/8 logdrop # Reserved
|
||||
7.0.0.0/8 logdrop # Reserved
|
||||
10.0.0.0/8 logdrop # Reserved
|
||||
23.0.0.0/8 logdrop # Reserved
|
||||
27.0.0.0/8 logdrop # Reserved
|
||||
31.0.0.0/8 logdrop # Reserved
|
||||
36.0.0.0/7 logdrop # Reserved
|
||||
39.0.0.0/8 logdrop # Reserved
|
||||
41.0.0.0/8 logdrop # Reserved
|
||||
42.0.0.0/8 logdrop # Reserved
|
||||
49.0.0.0/8 logdrop # JTC - Returned to IANA Mar 98
|
||||
50.0.0.0/8 logdrop # JTC - Returned to IANA Mar 98
|
||||
58.0.0.0/7 logdrop # Reserved
|
||||
70.0.0.0/7 logdrop # Reserved
|
||||
72.0.0.0/5 logdrop # Reserved
|
||||
85.0.0.0/8 logdrop # Reserved
|
||||
86.0.0.0/7 logdrop # Reserved
|
||||
88.0.0.0/5 logdrop # Reserved
|
||||
96.0.0.0/3 logdrop # Reserved
|
||||
127.0.0.0/8 logdrop # Loopback
|
||||
197.0.0.0/8 logdrop # Reserved
|
||||
198.18.0.0/15 logdrop # Reserved
|
||||
223.0.0.0/8 logdrop # Reserved - Returned by APNIC in 2003
|
||||
240.0.0.0/4 logdrop # Reserved
|
||||
#
|
||||
# End of generated entries
|
||||
#
|
||||
10.0.0.0/8 logdrop # RFC 1918
|
||||
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
|
||||
|
||||
@ -175,7 +175,7 @@ display_chains()
|
||||
# Send the output to a temporary file since ash craps if we try to store
|
||||
# the output in a variable.
|
||||
#
|
||||
iptables -L -n -v > /tmp/chains-$$
|
||||
iptables -L $IPT_OPTIONS > /tmp/chains-$$
|
||||
|
||||
clear
|
||||
echo "$banner $(date)"
|
||||
@ -289,7 +289,7 @@ packet_log() # $1 = number of messages
|
||||
sed s/" kernel:"// | \
|
||||
sed s/" $host $LOGFORMAT"/" "/ | \
|
||||
sed s/" $host kernel: ipt_unclean: "/" "/ | \
|
||||
sed 's/MAC=.*SRC=/SRC=/' | \
|
||||
sed 's/MAC=.* SRC=/SRC=/' | \
|
||||
tail $options
|
||||
}
|
||||
|
||||
@ -420,7 +420,7 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that
|
||||
echo
|
||||
echo "NAT Status"
|
||||
echo
|
||||
iptables -t nat -L -n -v
|
||||
iptables -t nat -L $IPT_OPTIONS
|
||||
timed_read
|
||||
|
||||
clear
|
||||
@ -429,7 +429,7 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that
|
||||
echo
|
||||
echo "TOS/MARK Status"
|
||||
echo
|
||||
iptables -t mangle -L -n -v
|
||||
iptables -t mangle -L $IPT_OPTIONS
|
||||
timed_read
|
||||
|
||||
clear
|
||||
@ -530,7 +530,7 @@ help()
|
||||
#
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
echo "Usage: $(basename $0) [debug|trace] [nolock] [-c <directory>] <command>"
|
||||
echo "Usage: $(basename $0) [debug|trace] [nolock] [-c <directory>] [ -x ] <command>"
|
||||
echo "where <command> is one of:"
|
||||
echo " add <interface>[:<host>] <zone>"
|
||||
echo " allow <address> ..."
|
||||
@ -585,6 +585,7 @@ if [ $# -gt 0 ] && [ "$1" = "nolock" ]; then
|
||||
fi
|
||||
|
||||
SHOREWALL_DIR=
|
||||
IPT_OPTIONS="-nv"
|
||||
done=0
|
||||
|
||||
while [ $done -eq 0 ]; do
|
||||
@ -605,6 +606,10 @@ while [ $done -eq 0 ]; do
|
||||
shift
|
||||
shift
|
||||
;;
|
||||
-x)
|
||||
IPT_OPTIONS="-xnv"
|
||||
shift
|
||||
;;
|
||||
*)
|
||||
done=1
|
||||
;;
|
||||
@ -710,14 +715,14 @@ case "$1" in
|
||||
echo "Shorewall-$version NAT at $HOSTNAME - $(date)"
|
||||
echo
|
||||
show_reset
|
||||
iptables -t nat -L -n -v
|
||||
iptables -t nat -L $IPT_OPTIONS
|
||||
;;
|
||||
tos|mangle)
|
||||
[ $# -gt 2 ] && usage 1
|
||||
echo "Shorewall-$version TOS at $HOSTNAME - $(date)"
|
||||
echo
|
||||
show_reset
|
||||
iptables -t mangle -L -n -v
|
||||
iptables -t mangle -L $IPT_OPTIONS
|
||||
;;
|
||||
log)
|
||||
[ $# -gt 2 ] && usage 1
|
||||
@ -748,10 +753,10 @@ case "$1" in
|
||||
show_reset
|
||||
if [ $# -gt 0 ]; then
|
||||
for chain in $*; do
|
||||
iptables -L $chain -n -v
|
||||
iptables -L $chain $IPT_OPTIONS
|
||||
done
|
||||
else
|
||||
iptables -L -n -v
|
||||
iptables -L $IPT_OPTIONS
|
||||
fi
|
||||
;;
|
||||
esac
|
||||
@ -775,17 +780,17 @@ case "$1" in
|
||||
echo
|
||||
show_reset
|
||||
host=$(echo $HOSTNAME | sed 's/\..*$//')
|
||||
iptables -L -n -v
|
||||
iptables -L $IPT_OPTIONS
|
||||
echo
|
||||
packet_log 20
|
||||
echo
|
||||
echo "NAT Table"
|
||||
echo
|
||||
iptables -t nat -L -n -v
|
||||
iptables -t nat -L $IPT_OPTIONS
|
||||
echo
|
||||
echo "Mangle Table"
|
||||
echo
|
||||
iptables -t mangle -L -n -v
|
||||
iptables -t mangle -L $IPT_OPTIONS
|
||||
echo
|
||||
cat /proc/net/ip_conntrack
|
||||
;;
|
||||
|
||||
@ -169,11 +169,29 @@ RFC1918_LOG_LEVEL=info
|
||||
# SMURF Log Level
|
||||
#
|
||||
# Specifies the logging level for smurf packets dropped by the
|
||||
#'nosmurfs' interface option in /etc/shorewall/interfaces. If set to the empty
|
||||
# value ( SMURF_LOG_LEVEL="" ) then dropped smurfs are not logged.
|
||||
#'nosmurfs' interface option in /etc/shorewall/interfaces and in
|
||||
# /etc/shorewall/hosts. If set to the empty value ( SMURF_LOG_LEVEL=""
|
||||
# ) then dropped smurfs are not logged.
|
||||
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
SMURF_LOG_LEVEL=info
|
||||
|
||||
#
|
||||
# BOGON Log Level
|
||||
#
|
||||
# Specifies the logging level for bogon packets dropped by the
|
||||
#'nobogons' interface option in /etc/shorewall/interfaces and in
|
||||
# /etc/shorewall/hosts. If set to the empty value
|
||||
# ( BOGON_LOG_LEVEL="" ) then packets whose TARGET is 'logdrop'
|
||||
# in /usr/share/shorewall/bogons are logged at the 'info' level.
|
||||
#
|
||||
# See the comment at the top of this section for a description of log levels
|
||||
#
|
||||
|
||||
BOGON_LOG_LEVEL=info
|
||||
################################################################################
|
||||
# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S
|
||||
################################################################################
|
||||
@ -417,7 +435,7 @@ MUTEX_TIMEOUT=60
|
||||
# established connection.
|
||||
#
|
||||
# If NEWNOTSYN is set to "No" or "no", then non-SYN packets that are not
|
||||
# part of an already established connection, it will be dropped by the
|
||||
# part of an already established connection will be dropped by the
|
||||
# firewall. The setting of LOGNEWNOTSYN above determines if these packets are
|
||||
# logged before they are dropped.
|
||||
#
|
||||
@ -429,7 +447,9 @@ MUTEX_TIMEOUT=60
|
||||
# also need to select NEWNOTSYN=Yes.
|
||||
#
|
||||
# The behavior of NEWNOTSYN=Yes may also be enabled on a per-interface basis
|
||||
# using the 'newnotsyn' option in /etc/shorewall/interfaces.
|
||||
# using the 'newnotsyn' option in /etc/shorewall/interfaces and on a
|
||||
# network or host basis using the same option in /etc/shorewall/hosts.
|
||||
|
||||
#
|
||||
# I find that NEWNOTSYN=No tends to result in lots of "stuck"
|
||||
# connections because any network timeout during TCP session tear down
|
||||
@ -524,6 +544,18 @@ MODULE_SUFFIX=
|
||||
# firewall system. This requires that you have ip6tables installed.
|
||||
|
||||
DISABLE_IPV6=Yes
|
||||
|
||||
#
|
||||
# BRIDGING
|
||||
#
|
||||
# If you wish to control traffic through a bridge (see http://bridge.sf.net),
|
||||
# then set BRIDGING=Yes. Your kernel must have the physdev match option
|
||||
# enabled; that option is available at the above URL for 2.4 kernels and
|
||||
# is included as a standard part of the 2.6 series kernels. If not
|
||||
# specified or specified as empty (BRIDGING="") then "No" is assumed.
|
||||
#
|
||||
|
||||
BRIDGING=No
|
||||
################################################################################
|
||||
# P A C K E T D I S P O S I T I O N
|
||||
################################################################################
|
||||
@ -534,6 +566,7 @@ DISABLE_IPV6=Yes
|
||||
# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,
|
||||
# DROP is assumed.
|
||||
#
|
||||
|
||||
BLACKLIST_DISPOSITION=DROP
|
||||
|
||||
#
|
||||
@ -552,8 +585,9 @@ MACLIST_DISPOSITION=REJECT
|
||||
#
|
||||
# This variable determins the disposition of packets having an invalid
|
||||
# combination of TCP flags that are received on interfaces having the
|
||||
# 'tcpflags' option specified in /etc/shorewall/interfaces. If not specified
|
||||
# or specified as empty (TCP_FLAGS_DISPOSITION="") then DROP is assumed.
|
||||
# 'tcpflags' option specified in /etc/shorewall/interfaces or in
|
||||
# /etc/shorewall/hosts. If not specified or specified as empty
|
||||
# (TCP_FLAGS_DISPOSITION="") then DROP is assumed.
|
||||
|
||||
TCP_FLAGS_DISPOSITION=DROP
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
%define name shorewall
|
||||
%define version 2.0.0b
|
||||
%define version 2.0.1
|
||||
%define release 1
|
||||
%define prefix /usr
|
||||
|
||||
@ -78,6 +78,7 @@ fi
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/interfaces
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/rules
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/nat
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/netmap
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/params
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/proxyarp
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/routestopped
|
||||
@ -133,14 +134,31 @@ fi
|
||||
%attr(0544,root,root) /usr/share/shorewall/firewall
|
||||
%attr(0544,root,root) /usr/share/shorewall/help
|
||||
%attr(0600,root,root) /usr/share/shorewall/rfc1918
|
||||
%attr(0600,root,root) /usr/share/shorewall/bogons
|
||||
|
||||
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
|
||||
|
||||
%changelog
|
||||
* Sat Mar 20 2004 Tom Eastep <tom@shorewall.net>
|
||||
- Update for 2.0.0b
|
||||
* Mon Apr 05 2004 Tom Eastep tom@shorewall.net
|
||||
- Updated for 2.0.1-1
|
||||
* Thu Apr 02 2004 Tom Eastep tom@shorewall.net
|
||||
- Updated for 2.0.1 RC5
|
||||
* Thu Apr 01 2004 Tom Eastep tom@shorewall.net
|
||||
- Updated for 2.0.1 RC4
|
||||
* Sun Mar 28 2004 Tom Eastep tom@shorewall.net
|
||||
- Updated for 2.0.1 RC3
|
||||
* Thu Mar 25 2004 Tom Eastep tom@shorewall.net
|
||||
- Updated for 2.0.1 RC2
|
||||
* Wed Mar 24 2004 Tom Eastep tom@shorewall.net
|
||||
- Updated for 2.0.1 RC1
|
||||
* Fri Mar 19 2004 Tom Eastep tom@shorewall.net
|
||||
- Updated for 2.0.1 Beta 2
|
||||
* Thu Mar 18 2004 Tom Eastep tom@shorewall.net
|
||||
- Added netmap file
|
||||
* Wed Mar 17 2004 Tom Eastep <tom@shorewall.net>
|
||||
- Update for 2.0.0a
|
||||
- Update for 2.0.1 Beta 1
|
||||
* Wed Mar 17 2004 Tom Eastep <tom@shorewall.net>
|
||||
- Add bogons file
|
||||
* Sat Mar 13 2004 Tom Eastep <tom@shorewall.net>
|
||||
- Update for 2.0.0 Final
|
||||
* Sat Mar 06 2004 Tom Eastep <tom@shorewall.net>
|
||||
|
||||
@ -26,7 +26,7 @@
|
||||
# You may only use this script to uninstall the version
|
||||
# shown below. Simply run this script to remove Seattle Firewall
|
||||
|
||||
VERSION=2.0.0b
|
||||
VERSION=2.0.1
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
|
||||
@ -1,11 +1,10 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="content-type"
|
||||
content="text/html; charset=UTF-8">
|
||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
<title>Banner</title>
|
||||
<meta name="author" content="Tom Eastep">
|
||||
<base target="main">
|
||||
<base target="_top">
|
||||
</head>
|
||||
<body style="color: rgb(0, 0, 0); background-color: rgb(51, 102, 255);"
|
||||
link="#000099" vlink="#990099" alink="#000099">
|
||||
|
||||
@ -18,9 +18,235 @@ Texts. A copy of the license is included in the section entitled “<span
|
||||
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
|
||||
Documentation License</a></span>”.<br>
|
||||
</p>
|
||||
<p>2004-01-30<br>
|
||||
<p>2004-04-05<br>
|
||||
</p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<p><b>3/14/2004 - Shorewall 2.0.0b </b><b></b></p>
|
||||
Corrects two problems:<br>
|
||||
<ol>
|
||||
<li>Thanks to Sean Mathews, the long-standing problem with
|
||||
Proxy ARP and IPSEC has been eliminated!</li>
|
||||
<li>The default value of the ALL INTERFACES column in
|
||||
/etc/shorewall/nat is documented as 'No' but the default continued to
|
||||
be 'Yes' as it was in Shorewall 1.4.<br>
|
||||
</li>
|
||||
</ol>
|
||||
<p><b>3/14/2004 - Shorewall 2.0.0a </b><b></b></p>
|
||||
<p>Corrects one problem:<br>
|
||||
</p>
|
||||
<ul>
|
||||
<li>Rules of the form:<br>
|
||||
<br>
|
||||
<action>
|
||||
zone1 zone2<br>
|
||||
<br>
|
||||
generated a warning stating that the rule was a policy.<br>
|
||||
</li>
|
||||
</ul>
|
||||
<p><b>3/14/2004 - Shorewall 2.0.0 </b><b><br>
|
||||
</b></p>
|
||||
<p>Dedicated to Agnes Van Slyke Eastep: March 14, 1910 - February
|
||||
23, 2004<br>
|
||||
</p>
|
||||
<p>Problems Corrected since 1.4.10<br>
|
||||
</p>
|
||||
<ol>
|
||||
<li>A blank USER/GROUP column in /etc/shorewall/tcrules no
|
||||
longer causes a [re]start error.</li>
|
||||
<li>The 'fgrep' utility is no longer required (caused startup
|
||||
problems on LEAF/Bering).</li>
|
||||
<li>The "shorewall add" command no longer inserts rules before
|
||||
checking of the blacklist.</li>
|
||||
<li>The 'detectnets' and 'routeback' options may now be used
|
||||
together with the intended effect.</li>
|
||||
<li>The following syntax previously produced an error:<br>
|
||||
<br>
|
||||
DNAT z1!z2,z3 z4...<br>
|
||||
</li>
|
||||
</ol>
|
||||
<p>Problems Corrected since RC2<br>
|
||||
<br>
|
||||
</p>
|
||||
<ol>
|
||||
<li>CONTINUE rules now work again.</li>
|
||||
<li>A comment in the rules file has been corrected.<br>
|
||||
</li>
|
||||
</ol>
|
||||
<p>Issues when migrating from Shorewall 1.4.x to Shorewall 2.0.0:<br>
|
||||
</p>
|
||||
<ol>
|
||||
<li>The 'dropunclean' and 'logunclean' interface options are no
|
||||
longer supported. If either option is specified in
|
||||
/etc/shorewall/interfaces, an threatening message will be generated.</li>
|
||||
<li>The NAT_BEFORE_RULES option has been removed from
|
||||
shorewall.conf. The behavior of Shorewall is as if NAT_BEFORE_RULES=No
|
||||
had been specified. In other words, DNAT rules now always take
|
||||
precidence over one-to-one NAT specifications.</li>
|
||||
<li>The default value for the ALL INTERFACES column in
|
||||
/etc/shorewall/nat has changed. In Shorewall 1.*, if the column was
|
||||
left empty, a value of "Yes" was assumed. This has been changed so that
|
||||
a value of "No" is now assumed.</li>
|
||||
<li>The following files don't exist in Shorewall 2.0:<br>
|
||||
/etc/shorewall/common.def<br>
|
||||
/etc/shorewall/common<br>
|
||||
/etc/shorewall/icmpdef<br>
|
||||
/etc/shorewall/action.template (Moved to /usr/share/shorewall)<br>
|
||||
/etc/shorewall/rfc1918 (Moved to /usr/share/shorewall).<br>
|
||||
<br>
|
||||
The /etc/shorewall/action file now allows an action to be designated as
|
||||
the "common" action for a particular policy type by following the
|
||||
action name with ":" and the policy (DROP, REJECT or ACCEPT).<br>
|
||||
<br>
|
||||
The file /usr/share/shorewall/actions.std has been added to define
|
||||
those actions that are released as part of Shorewall. In that file are
|
||||
two actions as follows:<br>
|
||||
<br>
|
||||
Drop:DROP<br>
|
||||
Reject:REJECT<br>
|
||||
<br>
|
||||
The "Drop" action is the common action for DROP policies while the
|
||||
"Reject" action is the default action for "REJECT" policies. These
|
||||
actions will be performed on packets prior to applying the DROP or
|
||||
REJECT policy respectively. In the first release, the difference
|
||||
between "Reject" and "Drop" is that "Reject" REJECTs SMB traffic while
|
||||
"Drop" silently drops such traffic.<br>
|
||||
<br>
|
||||
As described above, Shorewall allows a common action for ACCEPT
|
||||
policies but does not specify such an action in the default
|
||||
configuration.<br>
|
||||
<br>
|
||||
If for some reason, you don't wish to have a common DROP or REJECT
|
||||
action, just include :DROP or :REJECT respectively in your
|
||||
/etc/shorewall/actions file.<br>
|
||||
<br>
|
||||
The file /usr/share/shorewall/actions.std catalogs the standard actions
|
||||
and is processed prior to /etc/shorewall/actions. This causes a large
|
||||
number of actions to be defined. The files which define these aactions
|
||||
are also located in /usr/share/shorewall as is the he action template
|
||||
file (action.template).<br>
|
||||
<br>
|
||||
These actions may be used in the ACTION column of the rules column. So
|
||||
for example, to allow FTP from your loc zone to your firewall, you
|
||||
would place this rule in /etc/shorewall/rules:<br>
|
||||
<br>
|
||||
#ACTION
|
||||
SOURCE DEST<br>
|
||||
AllowFTP
|
||||
loc
|
||||
fw<br>
|
||||
<br>
|
||||
If you want to redefine any of the Shorewall-defined actions, simply
|
||||
copy the appropriate action file from /usr/share/shorewall to
|
||||
/etc/shorewall and modify the copy as desired. Your modified copy will
|
||||
be used rather than the original one in /usr/share/shorewall.<br>
|
||||
<br>
|
||||
Note: The 'dropBcast' and 'dropNonSyn' actions are built into Shorewall
|
||||
and may not be changed.<br>
|
||||
<br>
|
||||
Beginning with version 2.0.0-Beta2, Shorewall will only create a chain
|
||||
for those actions that are actually used.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>The /etc/shorewall directory no longer contains a 'users'
|
||||
file or a 'usersets' file. Similar functionality is now available using
|
||||
user-defined actions.<br>
|
||||
<br>
|
||||
Now, action files created by copying
|
||||
/usr/share/shorewall/action.template may specify a USER and or GROUP
|
||||
name/id in the final column just like in the rules file (see below). It
|
||||
is thus possible to create actions that control traffic from a list of
|
||||
users and/or groups.<br>
|
||||
<br>
|
||||
The last column in /etc/shorewall/rules is now labeled USER/GROUP and
|
||||
may contain:<br>
|
||||
<br>
|
||||
[!]<user number>[:]<br>
|
||||
[!]<user name>[:]<br>
|
||||
[!]:<group number><br>
|
||||
[!]:<group name><br>
|
||||
[!]<user number>:<group number><br>
|
||||
[!]<user number>:<group name><br>
|
||||
[!]<user name>:<group number><br>
|
||||
[!]<user name>:<group name><br>
|
||||
<br>
|
||||
</li>
|
||||
<li>It is no longer possible to specify rate limiting in the
|
||||
ACTION column of /etc/shorewall/rules -- you must use the RATE LIMIT
|
||||
column.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Depending on which method you use to upgrade, if you have
|
||||
your own version of /etc/shorewall/rfc1918, you may have to take
|
||||
special action to restore it after the upgrade. Look for
|
||||
/etc/shorewall/rfc1918*, locate the proper file and rename it back to
|
||||
/etc/shorewall/rfc1918. The contents of that file will supercede the
|
||||
contents of /usr/share/shorewall/rfc1918.</li>
|
||||
</ol>
|
||||
<p>New Features:<br>
|
||||
</p>
|
||||
<ol>
|
||||
<li>The INCLUDE directive now allows absolute file names.</li>
|
||||
<li>A 'nosmurfs' interface option has been added to
|
||||
/etc/shorewall/interfaces. When specified for an interface, this option
|
||||
causes smurfs (packets with a broadcast address as their source) to be
|
||||
dropped and optionally logged (based on the setting of a new
|
||||
SMURF_LOG_LEVEL option in shorewall.conf).</li>
|
||||
<li>fw->fw traffic may now be controlled by Shorewall. There
|
||||
is no need to define the loopback interface in
|
||||
/etc/shorewall/interfaces; you simply add a fw->fw policy and
|
||||
fw->fw rules. If you have neither a fw->fw policy nor fw->fw
|
||||
rules, all fw->fw traffic is allowed.</li>
|
||||
<li>There is a new PERSISTENT column in the proxyarp file. A
|
||||
value of "Yes" in this column means that the route added by Shorewall
|
||||
for this host will remain after a "shorewall stop" or "shorewall clear".</li>
|
||||
<li>"trace" is now a synonym for "debug" in /sbin/shorewall
|
||||
commands. So to trace the "start" command, you could enter:<br>
|
||||
<br>
|
||||
shorewall trace start 2> /tmp/trace<br>
|
||||
<br>
|
||||
The trace information would be written to the file /tmp/trace.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>When defining an ipsec tunnel in /etc/shorewall/tunnels, if
|
||||
you follow the tunnel type ("ipsec" or "ipsecnet") with ":noah" (e.g.,
|
||||
"ipsec:noah"), then Shorewall will only create rules for ESP (protocol
|
||||
50) and will not create rules for AH (protocol 51).</li>
|
||||
<li>A new DISABLE_IPV6 option has been added to shorewall.conf.
|
||||
When this option is set to "Yes", Shorewall will set the policy for the
|
||||
IPv6 INPUT, OUTPUT and FORWARD chains to DROP during "shorewall
|
||||
[re]start" and "shorewall stop". Regardless of the setting of this
|
||||
variable, "shorewall clear" will silently attempt to set these policies
|
||||
to ACCEPT.<br>
|
||||
<br>
|
||||
If this option is not set in your existing shorewall.conf then a
|
||||
setting of DISABLE_IPV6=No is assumed in which case, Shorewall will not
|
||||
touch any IPv6 settings except during "shorewall clear".</li>
|
||||
<li>The CONTINUE target is now available in action definitions.
|
||||
CONTINUE terminates processing of the current action and returns to the
|
||||
point where that action was invoked.</li>
|
||||
</ol>
|
||||
<p><b>2/15/2004 - Shorewall 1.4.10c </b></p>
|
||||
<p>Corrects one problem:<br>
|
||||
</p>
|
||||
Entries in /etc/shorewall/tcrules with an empty USER/GROUP column would
|
||||
cause a startup error.
|
||||
<p><b>2/12/2004 - Shorewall 1.4.10b </b><b></b></p>
|
||||
<p>Corrects one problem:<br>
|
||||
</p>
|
||||
<ul>
|
||||
<li>In the /etc/shorewall/masq entry “<span class="quote">eth0:!10.1.1.150
|
||||
0.0.0.0/0!10.1.0.0/16 10.1.2.16</span>”, the
|
||||
“<span class="quote">!10.1.0.0/16</span>” is ignored.</li>
|
||||
</ul>
|
||||
<p><b>2/8/2004 - Shorewall 1.4.10a </b><b></b></p>
|
||||
<p>Corrects two problems:<br>
|
||||
</p>
|
||||
<ul>
|
||||
<li>A problem which can cause [re]start to fail inexplicably
|
||||
while processing /etc/shorewall/masq.</li>
|
||||
<li>Interfaces using the Atheros WiFi card to use the 'maclist'
|
||||
option.</li>
|
||||
</ul>
|
||||
<p><b>1/30/2004 - Shorewall 1.4.10</b></p>
|
||||
<p>Problems Corrected since version 1.4.9</p>
|
||||
<ol>
|
||||
|
||||
@ -8,7 +8,6 @@
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
</head>
|
||||
<body>
|
||||
-+
|
||||
<h3><font color="#ff6633"></font></h3>
|
||||
<h1 style="text-align: center;">Visit Seattle in the Springtime!!!<br>
|
||||
</h1>
|
||||
|
||||
@ -7,54 +7,50 @@
|
||||
<base target="main">
|
||||
</head>
|
||||
<body>
|
||||
<table bgcolor="#3366ff" border="0" cellpadding="0" cellspacing="0"
|
||||
id="AutoNumber1" style="border-collapse: collapse;" width="100%">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td bgcolor="#ffffff" width="100%">
|
||||
<ul>
|
||||
<li> <a href="seattlefirewall_index.htm">Home</a></li>
|
||||
<li> <a href="shorewall_features.htm">Features</a></li>
|
||||
<li><a href="Shorewall_Doesnt.html">What it Cannot Do</a> </li>
|
||||
<li> <a href="shorewall_prerequisites.htm">Requirements</a></li>
|
||||
<li> <a href="download.htm">Download</a> </li>
|
||||
<li> <a href="Install.htm">Installation/Upgrade/</a> <a
|
||||
href="Install.htm">Configuration</a> </li>
|
||||
<li> <a href="shorewall_quickstart_guide.htm">QuickStart
|
||||
Guides (HOWTOs)</a> </li>
|
||||
<li> <b><a href="Documentation_Index.html">Documentation</a></b></li>
|
||||
<li> <a href="FAQ.htm">FAQs</a> (<a
|
||||
href="http://wiki.rettc.com/wiki.phtml?title=Wiki_Shorewall_FAQ"
|
||||
target="_top">Wiki</a>)<br>
|
||||
</li>
|
||||
<li><a href="useful_links.html">Useful Links</a> </li>
|
||||
<li> <a href="troubleshoot.htm">Things to try if it doesn't
|
||||
work</a></li>
|
||||
<li> <a href="errata.htm">Errata</a></li>
|
||||
<li> <a href="upgrade_issues.htm">Upgrade Issues</a></li>
|
||||
<li> <a href="support.htm">Getting help or Answers to Questions</a></li>
|
||||
<li><a href="http://lists.shorewall.net">Mailing Lists</a><a
|
||||
href="http://lists.shorewall.net"> </a> </li>
|
||||
<li><a href="shorewall_mirrors.htm">Mirrors</a> </li>
|
||||
<li> <a href="News.htm">News Archive</a></li>
|
||||
<li> <a
|
||||
href="http://cvs.shorewall.net/Shorewall_CVS_Access.html">CVS
|
||||
Repository</a></li>
|
||||
<li> <a href="quotes.htm">Quotes from Users</a></li>
|
||||
<li> <a href="shoreline.htm">About the Author</a></li>
|
||||
<li> <a href="seattlefirewall_index.htm#Donations">Donations</a></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p><a href="copyright.htm"><font size="2">Copyright © 2001-2004 Thomas
|
||||
M. Eastep.</font></a><br>
|
||||
</p>
|
||||
<ul>
|
||||
<small> </small><li style="font-weight: bold;"><a href="index.htm"
|
||||
target="_top">Home</a></li>
|
||||
<li style="font-weight: bold;"><a href="download.htm">Download</a></li>
|
||||
<li><a href="Install.htm"><span style="font-weight: bold;">Installation</span></a>
|
||||
</li>
|
||||
<li><b><a href="Documentation_Index.html">Documentation</a></b></li>
|
||||
<li><a href="FAQ.htm"><span style="font-weight: bold;">FAQ</span>s</a>
|
||||
(<a href="http://wiki.rettc.com/wiki.phtml?title=Wiki_Shorewall_FAQ"
|
||||
target="_top">Wiki</a>)</li>
|
||||
<li><a href="troubleshoot.htm"><span style="font-weight: bold;">Troubleshooting</span></a></li>
|
||||
<li><a href="support.htm"><span style="font-weight: bold;">Support</span></a></li>
|
||||
</ul>
|
||||
<span style="font-weight: bold;"></span>
|
||||
<div style="text-align: left;"><a href="http://www.shorewall.net"
|
||||
target="_top"><img alt="(Protected by Shorewall)"
|
||||
src="images/ProtectedBy.png"
|
||||
style="border: 0px solid ; width: 216px; height: 45px;" title=""></a></div>
|
||||
<ul>
|
||||
<li> <a href="shorewall_features.htm">Features</a></li>
|
||||
<li><a href="Shorewall_Doesnt.html">What it
|
||||
Cannot Do</a> </li>
|
||||
<li> <a href="shorewall_prerequisites.htm">Requirements</a></li>
|
||||
<li><a href="http://lists.shorewall.net">Mailing
|
||||
Lists</a><a href="http://lists.shorewall.net"> </a> </li>
|
||||
<li><a href="upgrade_issues.htm">Upgrade
|
||||
Issues</a></li>
|
||||
<li><a href="errata.htm">Errata</a></li>
|
||||
<li><a href="shorewall_mirrors.htm">Mirrors</a> </li>
|
||||
<li> <a href="News.htm">News Archive</a></li>
|
||||
<li> <a href="http://cvs.shorewall.net/Shorewall_CVS_Access.html">CVS
|
||||
Repository</a></li>
|
||||
<li> <a href="quotes.htm">Quotes from Users</a></li>
|
||||
<li><a href="useful_links.html">Useful Links</a></li>
|
||||
<li> <a href="shoreline.htm">About the Author</a></li>
|
||||
<li> <a href="seattlefirewall_index.htm#Donations">Donations</a></li>
|
||||
<small></small>
|
||||
</ul>
|
||||
<p><a href="copyright.htm"><font size="2">Copyright © 2001-2004 Thomas
|
||||
M. Eastep.</font></a><br>
|
||||
</p>
|
||||
<div style="text-align: left;"><a href="http://www.shorewall.net"
|
||||
target="_top"><br>
|
||||
</a></div>
|
||||
<p><br>
|
||||
<a href="copyright.htm"> </a> </p>
|
||||
</body>
|
||||
|
||||
@ -37,11 +37,14 @@ Guides (HOWTOs)</a><br>
|
||||
target="_top">Wiki</a>)</li>
|
||||
<li><a href="useful_links.html">Useful Links</a><br>
|
||||
</li>
|
||||
<li> <a href="troubleshoot.htm">Things to try if it doesn't
|
||||
<li> <a href="troubleshoot.htm"><span
|
||||
style="font-weight: bold;">Troubleshooting - </span>Things to try if
|
||||
it doesn't
|
||||
work</a></li>
|
||||
<li> <a href="errata.htm">Errata</a></li>
|
||||
<li> <a href="upgrade_issues.htm">Upgrade Issues</a></li>
|
||||
<li> <a href="support.htm">Getting help or Answers to Questions</a></li>
|
||||
<li> <a href="support.htm"><span style="font-weight: bold;">Support
|
||||
- </span>Getting help or Answers to Questions</a></li>
|
||||
<li><a href="http://lists.shorewall.net">Mailing Lists</a><a
|
||||
href="http://lists.shorewall.net"> </a><br>
|
||||
</li>
|
||||
@ -66,7 +69,11 @@ Repository</a></li>
|
||||
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
|
||||
size="2">2001-2004 Thomas M. Eastep.</font></a><br>
|
||||
</p>
|
||||
<h1 align="center"><b><a href="http://www.sf.net"><img align="left"
|
||||
alt="SourceForge Logo"
|
||||
src="http://sourceforge.net/sflogo.php?group_id=22587&type=3"></a></b></h1>
|
||||
<br>
|
||||
<br>
|
||||
<b><b>This site is hosted by the generous folks at <a
|
||||
href="http://www.sf.net">SourceForge.net</a></b></b>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -22,7 +22,7 @@ Texts. A copy of the license is included in the section entitled “<span
|
||||
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
|
||||
Documentation License</a></span>”.<br>
|
||||
</p>
|
||||
<p>2004-01-13<br>
|
||||
<p>2004-03-01<br>
|
||||
</p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<p><b>I strongly urge you to read and print a copy of the <a
|
||||
@ -128,8 +128,7 @@ removing the file /etc/shorewall/startup_disabled.</b></font></p>
|
||||
<tr>
|
||||
<td>France</td>
|
||||
<td>Shorewall.net</td>
|
||||
<td><a
|
||||
href="http://france.shorewall.net/pub/shorewall/LATEST.lrp">Browse</a></td>
|
||||
<td><a href="http://france.shorewall.net/pub/shorewall">Browse</a></td>
|
||||
<td> <a target="_blank"
|
||||
href="ftp://france.shorewall.net/pub/mirrors/shorewall/">Browse</a></td>
|
||||
</tr>
|
||||
|
||||
@ -3,6 +3,7 @@ Frameset//EN""http://www.w3.org/TR/html4/frameset.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<title>Shoreline Firewall</title>
|
||||
<LINK REL="SHORTCUT ICON" HREF="favicon.ico">
|
||||
<meta http-equiv="Content-Type" content="text/html;
|
||||
charset=UTF-8"></head>
|
||||
<frameset rows="110,*" cols="*" frameborder="yes"
|
||||
|
||||
@ -27,7 +27,7 @@ Documentation License</a></span>
|
||||
</div>
|
||||
</div>
|
||||
<div>
|
||||
<p class="pubdate">2004-01-28<br>
|
||||
<p class="pubdate">2004-03-15<br>
|
||||
</p>
|
||||
<hr style="width: 100%; height: 2px;"></div>
|
||||
<h2>Note</h2>
|
||||
@ -52,7 +52,7 @@ allow HTML in list posts!!<br>
|
||||
I think that blocking all HTML is a Draconian way to control spam and
|
||||
that the ultimate losers here are not the spammers but the list
|
||||
subscribers whose MTAs are bouncing all shorewall.net mail. As one list
|
||||
subscriber wrote to me privately "These e-mail admin's need to get a <i>(explitive
|
||||
subscriber wrote to me privately "These e-mail admin's need to get a <i>(expletive
|
||||
deleted)</i> life instead of trying to
|
||||
rid the planet of HTML based e-mail". Nevertheless, to allow
|
||||
subscribers to receive list posts as must as possible, I have now
|
||||
@ -61,6 +61,11 @@ outgoing posts.
|
||||
This means that HTML-only posts will be bounced by the list server.<br>
|
||||
<p align="left"> <b>Note: </b>The list server limits posts to 120kb.<br>
|
||||
</p>
|
||||
<h2>Please don't hijack another poster's thread</h2>
|
||||
On shorewall.net as elsewhere, it is considered very bad netiquette to
|
||||
hijack another poster's thread by simply replying to a list post and
|
||||
changing the subject to a different one. Please start a new thread when
|
||||
you wish to introduce a new topic for discussion.<br>
|
||||
<h2>Other Mail Delivery Problems</h2>
|
||||
If you find that you are missing an occasional list post, your e-mail
|
||||
admin may be blocking mail whose <i>Received:</i> headers contain the
|
||||
@ -111,29 +116,12 @@ in your browser. If you don't wish to trust my certificates then you
|
||||
can either use unencrypted access when subscribing to Shorewall mailing
|
||||
lists or you can use secure access (SSL) and
|
||||
accept the server's certificate when prompted by your browser.<br>
|
||||
<h2 align="left">Shorewall Newbies Mailing List</h2>
|
||||
This list provides a place where people who are new to Shorewall can
|
||||
get questions answered and can receive help with problems.<br>
|
||||
<p align="left" style="color: rgb(255, 0, 0);"><big><b>Before posting
|
||||
to this list, please see the <a href="http://shorewall.net/support.htm">problem
|
||||
reporting guidelines</a>.<br>
|
||||
</b></big></p>
|
||||
<p align="left">To subscribe: <a
|
||||
href="https://lists.shorewall.net/mailman/listinfo/shorewall-newbies"
|
||||
target="_top">https//lists.shorewall.net/mailman/listinfo/shorewall-newbies</a></p>
|
||||
<p align="left"> To post to the list, post to <a
|
||||
href="mailto:shorewall-newbies@lists.shorewall.net">shorewall-newbies@lists.shorewall.net</a>.<br>
|
||||
</p>
|
||||
<p align="left">The list archives are at <a
|
||||
href="http://lists.shorewall.net/pipermail/shorewall-newbies/index.html">http://lists.shorewall.net/pipermail/shorewall-newbies</a>.</p>
|
||||
<h2 align="left">Shorewall Users Mailing List</h2>
|
||||
<p align="left">The Shorewall Users Mailing list provides a way for
|
||||
users to get answers to questions and to report problems. Information
|
||||
of general interest to the Shorewall user community is also posted to
|
||||
this list.<br>
|
||||
</p>
|
||||
<p align="left">The Shorewall author does not monitor this list.<br>
|
||||
</p>
|
||||
<p align="left" style="color: rgb(255, 0, 0);"><big><b>Before posting
|
||||
to this list, please see the <a href="http://shorewall.net/support.htm">problem
|
||||
reporting guidelines</a>.<br>
|
||||
@ -186,7 +174,19 @@ USE THIS LIST FOR REPORTING PROBLEMS OR ASKING FOR HELP.</span></span></big></p>
|
||||
<p align="left"> To post to the list, post to <a
|
||||
href="mailto:shorewall-devel@lists.shorewall.net">shorewall-devel@lists.shorewall.net</a>. </p>
|
||||
<p align="left">The list archives are at <a
|
||||
href="http://lists.shorewall.net/pipermail/shorewall-devel">http://lists.shorewall.net/pipermail/shorewall-devel</a>.</p>
|
||||
href="http://lists.shorewall.net/pipermail/shorewall-devel">http://lists.shorewall.net/pipermail/shorewall-devel</a>.<br>
|
||||
</p>
|
||||
<h2 align="left">Shorewall Newbies Mailing List (Closed)<br>
|
||||
</h2>
|
||||
This list previously provided a place where people who are new to
|
||||
Shorewall could
|
||||
get questions answered and could receive help with problems. It proved
|
||||
to be less that a success and has been discontinued.<br>
|
||||
<p align="left">To unsubscribe: <a
|
||||
href="https://lists.shorewall.net/mailman/listinfo/shorewall-newbies"
|
||||
target="_top">https//lists.shorewall.net/mailman/listinfo/shorewall-newbies</a></p>
|
||||
<p align="left">The list archives are at <a
|
||||
href="http://lists.shorewall.net/pipermail/shorewall-newbies/index.html">http://lists.shorewall.net/pipermail/shorewall-newbies</a>.</p>
|
||||
<h2 align="left"><a name="Unsubscribe"></a>How to Unsubscribe from one
|
||||
of the Mailing Lists</h2>
|
||||
<p align="left">There seems to be near-universal confusion about
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
<head>
|
||||
<meta content="HTML Tidy, see www.w3.org" name="generator">
|
||||
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
|
||||
<title>Shoreline Firewall (Shorewall) 1.4</title>
|
||||
<title>Shoreline Firewall (Shorewall) 2.0</title>
|
||||
<base target="_self">
|
||||
</head>
|
||||
<body>
|
||||
@ -14,18 +14,26 @@
|
||||
<tr>
|
||||
<td width="90%">
|
||||
<h2>Introduction to Shorewall</h2>
|
||||
<h3>This is the Shorewall 1.4 Web Site</h3>
|
||||
The information on this site applies only to 1.4.x releases of
|
||||
<h3>This is the Shorewall 2.0 Web Site</h3>
|
||||
<div style="margin-left: 40px;">The information on this site
|
||||
applies only to 2.0.x releases of
|
||||
Shorewall. For older versions:<br>
|
||||
</div>
|
||||
<ul>
|
||||
<li>The 1.3 site is <a href="http://www.shorewall.net/1.3"
|
||||
<ul>
|
||||
<li>The 1.4 site is <a href="http://www.shorewall.net/1.4"
|
||||
target="_top">here.<br>
|
||||
</a></li>
|
||||
<li>The 1.3 site is <a href="http://www.shorewall.net/1.3"
|
||||
target="_top">here.</a></li>
|
||||
<li>The 1.2 site is <a href="http://shorewall.net/1.2/"
|
||||
<li>The 1.2 site is <a href="http://shorewall.net/1.2/"
|
||||
target="_top">here</a>.</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<h3>Glossary</h3>
|
||||
<ul>
|
||||
<li><a href="http://www.netfilter.org">Netfilter</a> - the
|
||||
<li><a href="http://www.netfilter.org" target="_top">Netfilter</a>
|
||||
- the
|
||||
packet filter facility built into the 2.4 and later Linux kernels.</li>
|
||||
<li>ipchains - the packet filter facility built into the 2.2
|
||||
Linux kernels. Also the name of the utility program used to configure
|
||||
@ -37,7 +45,8 @@ combination of iptables+Netfilter (with Netfilter not in ipchains
|
||||
compatibility mode).</li>
|
||||
</ul>
|
||||
<h3>What is Shorewall?</h3>
|
||||
The Shoreline Firewall, more commonly known as "Shorewall", is
|
||||
<div style="margin-left: 40px;">The Shoreline Firewall, more
|
||||
commonly known as "Shorewall", is
|
||||
high-level tool for configuring Netfilter. You describe your
|
||||
firewall/gateway requirements using entries in a set of configuration
|
||||
files. Shorewall reads those configuration files and with the help of
|
||||
@ -45,223 +54,196 @@ the iptables utility, Shorewall configures Netfilter to match your
|
||||
requirements. Shorewall can be used on a dedicated firewall system, a
|
||||
multi-function gateway/router/server or on a standalone GNU/Linux
|
||||
system. Shorewall does not use Netfilter's ipchains compatibility mode
|
||||
and can thus take advantage of Netfilter's connection state tracking
|
||||
capabilities.<br>
|
||||
and can thus take advantage of Netfilter's <a
|
||||
href="http://www.cs.princeton.edu/%7Ejns/security/iptables/iptables_conntrack.html"
|
||||
target="_top">connection
|
||||
state tracking
|
||||
capabilities</a>.<br>
|
||||
<br>
|
||||
Shorewall is <span style="text-decoration: underline;">not</span> a
|
||||
daemon. Once Shorewall has configured Netfilter, it's job is complete
|
||||
although the <a href="starting_and_stopping_shorewall.htm">/sbin/shorewall
|
||||
daemon. Once Shorewall has configured Netfilter, it's job is complete.
|
||||
After that, there is no Shorewall code running although the <a
|
||||
href="starting_and_stopping_shorewall.htm">/sbin/shorewall
|
||||
program can be used at any time to monitor the Netfilter firewall</a>.<br>
|
||||
</div>
|
||||
<h3>Getting Started with Shorewall</h3>
|
||||
New to Shorewall? Start by selecting the <a
|
||||
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most
|
||||
<div style="margin-left: 40px;">New to Shorewall? Start by
|
||||
selecting the <a href="shorewall_quickstart_guide.htm">QuickStart Guide</a>
|
||||
that most
|
||||
closely match your environment and follow the step by step instructions.<br>
|
||||
</div>
|
||||
<h3>Looking for Information?</h3>
|
||||
The <a href="Documentation_Index.html">Documentation
|
||||
<div style="margin-left: 40px;">The <a
|
||||
href="Documentation_Index.html">Documentation
|
||||
Index</a> is a good place to start as is the Quick Search in the frame
|
||||
above.
|
||||
<h3>License</h3>
|
||||
This program is free software; you can redistribute it and/or modify it
|
||||
under the terms of <a href="http://www.gnu.org/licenses/gpl.html">Version
|
||||
2 of the GNU General Public License</a> as published by the Free
|
||||
Software Foundation.<br>
|
||||
<p>This program is distributed in the hope that it will be
|
||||
useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
General Public License for more detail.</p>
|
||||
<p>You should have received a copy of the GNU General Public
|
||||
License along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA</p>
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.2 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover, and with no Back-Cover Texts.
|
||||
A copy of the license is included in the section entitled <a>"GNU Free
|
||||
Documentation License"</a>.
|
||||
<p>Copyright © 2001-2004 Thomas M. Eastep </p>
|
||||
<h3>Running Shorewall on Mandrake with a two-interface setup?</h3>
|
||||
If so, the documentation <b></b>on this site will not apply directly
|
||||
above. </div>
|
||||
<h3>Running Shorewall on Mandrake® with a two-interface setup?</h3>
|
||||
<div style="margin-left: 40px;">If so, the documentation on this
|
||||
site will not apply directly
|
||||
to your setup. If you want to use the documentation that you find here,
|
||||
you will want to consider uninstalling what you have and installing a
|
||||
setup that matches the documentation on this site. See the <a
|
||||
href="two-interface.htm">Two-interface QuickStart Guide</a> for
|
||||
details.<br>
|
||||
<br>
|
||||
<span style="font-weight: bold;">Update: </span>I've been
|
||||
informed by Mandrake Development that this problem has been corrected
|
||||
in Mandrake 10.0 Final (the problem still exists in the 10.0 Community
|
||||
release).<br>
|
||||
</div>
|
||||
<h3>License</h3>
|
||||
<div style="margin-left: 40px;">This program is free software;
|
||||
you can redistribute it and/or modify it
|
||||
under the terms of <a href="http://www.gnu.org/licenses/gpl.html">Version
|
||||
2 of the GNU General Public License</a> as published by the Free
|
||||
Software Foundation.<br>
|
||||
</div>
|
||||
<p style="margin-left: 40px;">This program is distributed in the
|
||||
hope that it will be
|
||||
useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
General Public License for more detail.</p>
|
||||
<div style="margin-left: 40px;"> </div>
|
||||
<p style="margin-left: 40px;">You should have received a copy of
|
||||
the GNU General Public
|
||||
License along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA</p>
|
||||
<div style="margin-left: 40px;">Permission is granted to copy,
|
||||
distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.2 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover, and with no Back-Cover Texts.
|
||||
A copy of the license is included in the section entitled <a>"GNU Free
|
||||
Documentation License"</a>. </div>
|
||||
<p>Copyright © 2001-2004 Thomas M. Eastep </p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<h2>News</h2>
|
||||
<p><b>1/30/2004 - Shorewall 1.4.10</b><b> <img alt="(New)"
|
||||
<p><b>4/5/2004 - Shorewall 2.0.1 </b><b> <img alt="(New)"
|
||||
src="images/new10.gif"
|
||||
style="border: 0px solid ; width: 28px; height: 12px;" title=""></b></p>
|
||||
<p>Problems Corrected since version 1.4.9</p>
|
||||
style="border: 0px solid ; width: 28px; height: 12px;" title=""></b><br>
|
||||
<b></b></p>
|
||||
Problems Corrected since 2.0.0<br>
|
||||
<br>
|
||||
<ol>
|
||||
<li>The column descriptions in the action.template file did not
|
||||
match the column headings. That has been corrected.</li>
|
||||
<li>The presence of IPV6 addresses on devices generated error
|
||||
messages during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes
|
||||
are specified in /etc/shorewall/shorewall.conf. These messages have
|
||||
been eliminated.</li>
|
||||
<li>The CONTINUE action in /etc/shorewall/rules now works
|
||||
correctly. A couple of problems involving rate limiting have been
|
||||
corrected. These bug fixes courtesy of Steven Jan Springl.</li>
|
||||
<li>Shorewall now tried to avoid sending an ICMP response to
|
||||
broadcasts and smurfs.</li>
|
||||
<li>Specifying "-" or "all" in the PROTO column of an action no
|
||||
longer causes a startup error. <br>
|
||||
<br>
|
||||
<li>Using actions in the manner recommended in the
|
||||
documentation results in a Warning that the rule is a policy.</li>
|
||||
<li>When a zone on a single interface is defined using
|
||||
/etc/shorewall/hosts, superfluous rules are generated in the
|
||||
<zone>_frwd chain.</li>
|
||||
<li>Thanks to Sean Mathews, a long-standing problem with Proxy
|
||||
ARP and IPSEC has been corrected. Thanks Sean!!!</li>
|
||||
<li>The "shorewall show log" and "shorewall logwatch" commands
|
||||
incorrectly displayed type 3 ICMP packets.<br>
|
||||
</li>
|
||||
</ol>
|
||||
Migragion Issues:<br>
|
||||
<br>
|
||||
None.<br>
|
||||
Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:<br>
|
||||
<br>
|
||||
<ol>
|
||||
<li>The function of 'norfc1918' is now split between that
|
||||
option and a new 'nobogons' option.<br>
|
||||
<br>
|
||||
The rfc1918 file released with Shorewall now contains entries for only
|
||||
those three address ranges reserved by RFC 1918. A 'nobogons' interface
|
||||
option has been added which handles bogon source addresses (those which
|
||||
are reserved by the IANA, those reserved for DHCP auto-configuration
|
||||
and the class C test-net reserved for testing and documentation
|
||||
examples). This will allow users to perform RFC 1918 filtering without
|
||||
having to deal with out of date data from IANA. Those who are willing
|
||||
to update their /usr/share/shorewall/bogons file regularly can specify
|
||||
the 'nobogons' option in addition to 'norfc1918'.<br>
|
||||
<br>
|
||||
The level at which bogon packets are logged is specified in the new
|
||||
BOGON_LOG_LEVEL variable in shorewall.conf. If that option is not
|
||||
specified or is specified as empty (e.g, BOGON_LOG_LEVEL="") then bogon
|
||||
packets whose TARGET is 'logdrop' in /usr/share/shorewall/bogons are
|
||||
logged at the 'info' level.</li>
|
||||
</ol>
|
||||
New Features:<br>
|
||||
<ol>
|
||||
<li>The INTERFACE column in the /etc/shorewall/masq file may
|
||||
now specify a destination list. <br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
#INTERFACE
|
||||
SUBNET ADDRESS<br>
|
||||
eth0:192.0.2.3,192.0.2.16/28 eth1<br>
|
||||
<br>
|
||||
If the list begins with "!" then SNAT will occur only if the
|
||||
destination IP address is NOT included in the list.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Output traffic control rules (those with the firewall as
|
||||
the source) may now be qualified by the effective userid and/or
|
||||
effective group id of the program generating the output. This feature
|
||||
is courtesy of Frédéric LESPEZ.<br>
|
||||
<br>
|
||||
A new USER column has been added to /etc/shorewall/tcrules. It may
|
||||
contain :<br>
|
||||
<br>
|
||||
[<user name or number>]:[<group
|
||||
name or number>]<br>
|
||||
<br>
|
||||
The colon is optionnal when specifying only a user.<br>
|
||||
<br>
|
||||
Examples : john: / john / :users /
|
||||
john:users<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>A "detectnets" interface option has been added for entries
|
||||
in /etc/shorewall/interfaces. This option automatically taylors the
|
||||
definition of the zone named in the ZONE column to include just
|
||||
those hosts that have routes through the interface named in the
|
||||
INTERFACE column. The named interface must be UP when Shorewall is
|
||||
[re]started.<br>
|
||||
<br>
|
||||
WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE! <br>
|
||||
</li>
|
||||
</ol>
|
||||
<p><b>1/17/2004 - FAQ Wiki Available </b><b></b></p>
|
||||
<p>It has been asserted that the use of CVS for maintaining the
|
||||
Shorewall documentation has been a barrier to community participation.
|
||||
To test this theory, Alex Martin <a
|
||||
href="http://wiki.rettc.com/wiki.phtml?title=Wiki_Shorewall_FAQ">has
|
||||
created a Wiki</a> and with the help of Mike Noyes has populated the
|
||||
Wiki with the Shorewall FAQ. <br>
|
||||
</p>
|
||||
<p><b>1/13/2004 - Shorewall 1.4.9 </b><b> </b></p>
|
||||
<p>Problems Corrected since version 1.4.8:</p>
|
||||
<ol>
|
||||
<li>There has been a low continuing level of confusion over the
|
||||
terms "Source NAT" (SNAT) and "Static NAT". To avoid future confusion,
|
||||
all instances of "Static NAT" have been replaced with "One-to-one NAT"
|
||||
in the documentation and configuration files.</li>
|
||||
<li>The description of NEWNOTSYN in shorewall.conf has been
|
||||
reworded for clarity.</li>
|
||||
<li>Wild-card rules (those involving "all" as SOURCE or DEST)
|
||||
will no longer produce an error if they attempt to add a rule that
|
||||
would override a NONE policy. The logic for expanding these wild-card
|
||||
rules now simply skips those (SOURCE,DEST) pairs that have a NONE
|
||||
policy.</li>
|
||||
<li>DNAT rules that also specified SNAT now work reliably.
|
||||
Previously, there were cases where the SNAT specification was
|
||||
effectively ignored.<br>
|
||||
</li>
|
||||
</ol>
|
||||
<p>Migration Issues:</p>
|
||||
<p> None.<br>
|
||||
<br>
|
||||
New Features: </p>
|
||||
<ol>
|
||||
<li>The documentation has been completely rebased to Docbook
|
||||
XML. The documentation is now released as separate HTML and XML
|
||||
packages.<br>
|
||||
<li>Support for Bridging Firewalls has been added. For details,
|
||||
see<br>
|
||||
<br>
|
||||
http://shorewall.net/bridge.html<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>To cut down on the number of "Why are these ports closed
|
||||
rather than stealthed?" questions, the SMB-related rules in
|
||||
/etc/shorewall/common.def have been changed from 'reject' to 'DROP'.</li>
|
||||
<li>For easier identification, packets logged under the
|
||||
'norfc1918' interface option are now logged out of chains named
|
||||
'rfc1918'. Previously, such packets were logged under chains named
|
||||
'logdrop'.</li>
|
||||
<li>Distributors and developers seem to be regularly inventing
|
||||
new naming conventions for kernel modules. To avoid the need to change
|
||||
Shorewall code for each new convention, the MODULE_SUFFIX option has
|
||||
been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix
|
||||
for module names in your particular distribution. If MODULE_SUFFIX is
|
||||
not set in shorewall.conf, Shorewall will use the list "o gz ko o.gz".<br>
|
||||
<li>Support for NETMAP has been added. NETMAP allows NAT to be
|
||||
defined between two network:<br>
|
||||
<br>
|
||||
To see what suffix is used by your distribution:<br>
|
||||
|
||||
a.b.c.1 -> x.y.z.1<br>
|
||||
|
||||
a.b.c.2 -> x.y.z.2<br>
|
||||
|
||||
a.b.c.3 -> x.y.z.3<br>
|
||||
...<br>
|
||||
<br>
|
||||
ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
|
||||
http://shorewall.net/netmap.htm<br>
|
||||
<br>
|
||||
All of the files listed should have the same suffix (extension). Set
|
||||
MODULE_SUFFIX to that suffix.<br>
|
||||
<br>
|
||||
Examples:<br>
|
||||
<br>
|
||||
If all files end in ".kzo" then set
|
||||
MODULE_SUFFIX="kzo"<br>
|
||||
If all files end in ".kz.o" then set
|
||||
MODULE_SUFFIX="kz.o"</li>
|
||||
<li>Support for user defined rule ACTIONS has been implemented
|
||||
through two new files:<br>
|
||||
<br>
|
||||
/etc/shorewall/actions - used to list the user-defined ACTIONS.<br>
|
||||
/etc/shorewall/action.template - For each user defined <action>,
|
||||
copy this file to /etc/shorewall/action.<action> and add the
|
||||
appropriate rules for that <action>. Once an <action> has
|
||||
been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
|
||||
DROP, etc.) in /etc/shorewall/rules.<br>
|
||||
<br>
|
||||
Example: You want an action that logs a packet at the 'info' level and
|
||||
accepts the connection.<br>
|
||||
<br>
|
||||
In /etc/shorewall/actions, you would add:<br>
|
||||
<br>
|
||||
LogAndAccept<br>
|
||||
<br>
|
||||
You would then copy /etc/shorewall/action.template to
|
||||
/etc/shorewall/action.LogAndAccept and in that file, you would add the
|
||||
two
|
||||
rules:<br>
|
||||
LOG:info<br>
|
||||
ACCEPT<br>
|
||||
</li>
|
||||
<li>The default value for NEWNOTSYN in shorewall.conf is now
|
||||
"Yes" (non-syn TCP packets that are not part of an existing connection
|
||||
are filtered according to the rules and policies rather than being
|
||||
dropped). I have made this change for two reasons:<br>
|
||||
<li>The /sbin/shorewall program now accepts a "-x" option to
|
||||
cause iptables to print out the actual packet and byte counts rather
|
||||
than abbreviated counts such as "13MB".<br>
|
||||
<br>
|
||||
a) NEWNOTSYN=No tends to result in lots of "stuck" connections since
|
||||
any timeout during TCP session tear down results in the firewall
|
||||
dropping all of the retries.<br>
|
||||
Commands affected by this are:<br>
|
||||
<br>
|
||||
b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in
|
||||
lots of confusing messages when a connection got "stuck". While I could
|
||||
have changed the default value of LOGNEWNOTSYN to suppress logging, I
|
||||
dislike defaults that silently throw away packets.</li>
|
||||
<li>The common.def file now contains an entry that silently
|
||||
drops ICMP packets with a null source address. Ad Koster reported a
|
||||
case where these were occuring frequently as a result of a broken
|
||||
system on his external network.<br>
|
||||
|
||||
shorewall -x show [ <chain>[ <chain> ...] ]<br>
|
||||
|
||||
shorewall -x show tos|mangle<br>
|
||||
|
||||
shorewall -x show nat<br>
|
||||
|
||||
shorewall -x status<br>
|
||||
|
||||
shorewall -x monitor [ <interval> ]<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Shorewall now traps two common zone definition errors:<br>
|
||||
<ul>
|
||||
<li>Including the firewall zone in a /etc/shorewall/hosts
|
||||
record.</li>
|
||||
<li>Defining an interface for a zone in both
|
||||
/etc/shorewall/interfaces and /etc/shorewall/hosts.<br>
|
||||
<br>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>In the second case, the following will appear during
|
||||
"shorewall [re]start" or "shorewall check":<br>
|
||||
<br>
|
||||
Determining Hosts in Zones...<br>
|
||||
...<br>
|
||||
Error: Invalid zone definition for zone
|
||||
<name of zone><br>
|
||||
Terminated<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>To support bridging, the following options have been added
|
||||
to entries in /etc/shorewall/hosts:<br>
|
||||
<br>
|
||||
norfc1918<br>
|
||||
nobogons<br>
|
||||
blacklist<br>
|
||||
tcpflags<br>
|
||||
nosmurfs<br>
|
||||
newnotsyn<br>
|
||||
<br>
|
||||
With the exception of 'newnotsyn', these options are only useful when
|
||||
the entry refers to a bridge port.<br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
#ZONE HOST(S)
|
||||
OPTIONS<br>
|
||||
net
|
||||
br0:eth0
|
||||
norfc1918,nobogons,blacklist,tcpflags,nosmurfs<br>
|
||||
<br>
|
||||
</li>
|
||||
</ol>
|
||||
<p><a href="News.htm">More News</a></p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<p><a href="http://leaf.sourceforge.net" target="_top"><img
|
||||
alt="(Leaf Logo)"
|
||||
style="border: 0px solid ; height: 36px; width: 49px;"
|
||||
@ -277,24 +259,27 @@ Bering 1.2!!!</b><br>
|
||||
<div>
|
||||
<div style="text-align: center;"> </div>
|
||||
</div>
|
||||
<h2><a name="Donations"></a>Donations</h2>
|
||||
<p style="text-align: left;"><a href="http://www.starlight.org"><img
|
||||
align="left" alt="(Starlight Logo)" hspace="10" src="images/newlog.gif"
|
||||
style="border: 4px solid ; width: 57px; height: 100px;" title=""></a><br>
|
||||
<big>Shorewall is free but if you try it and find it useful,
|
||||
please consider making a donation to <a href="http://www.starlight.org">Starlight
|
||||
Children's Foundation</a>. Thanks!</big><br>
|
||||
<a href="http://www.starlight.org"></a></p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<h2><a name="Donations"></a>Donations<br>
|
||||
</h2>
|
||||
<p style="text-align: left;"> <big><img
|
||||
src="images/alz_logo2.gif" title=""
|
||||
alt="(Alzheimer's Association Logo)"
|
||||
style="width: 300px; height: 60px;" align="left">Shorewall is free but
|
||||
if you
|
||||
try it and find it useful,
|
||||
please consider making a donation to the <a href="http://www.alz.org/"
|
||||
target="_top">Alzheimer's Association</a>. Thanks!</big> </p>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="vertical-align: top;"><br>
|
||||
<td style="vertical-align: top;"> <br>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p><font size="2">Updated 01/30/2004 - <a href="support.htm">Tom Eastep</a></font><br>
|
||||
<p><font size="2">Updated 04/05/2004 - <a href="support.htm">Tom Eastep</a></font><br>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -10,6 +10,13 @@
|
||||
<body>
|
||||
<p align="center"> </p>
|
||||
<h1 style="text-align: left;">Tom Eastep</h1>
|
||||
<span style="font-style: italic;">Perfection in design is achieved not
|
||||
when there is nothing left to add, but rather when there is nothing
|
||||
left to take away.</span><br>
|
||||
<br>
|
||||
<div style="text-align: center;"> - Antoine de Saint-Exupery<br>
|
||||
</div>
|
||||
<br>
|
||||
Copyright © 2001-2003 Thomas M. Eastep<br>
|
||||
<br>
|
||||
<p>Permission is granted to copy, distribute and/or modify this
|
||||
@ -30,16 +37,21 @@ Documentation License</a></span>”.<br>
|
||||
<p align="center"><br>
|
||||
</p>
|
||||
<ul>
|
||||
<li>Born 1945 in <a href="http://www.experiencewashington.com">Washington
|
||||
<li>Born 1945 in <a href="http://www.experiencewashington.com"
|
||||
target="_top">Washington
|
||||
State</a> .</li>
|
||||
<li>BA Mathematics from <a href="http://www.wsu.edu">Washington
|
||||
<li>BA Mathematics from <a href="http://www.wsu.edu" target="_top">Washington
|
||||
State University</a> 1967</li>
|
||||
<li>MA Mathematics from <a href="http://www.washington.edu">University
|
||||
<li>MA Mathematics from <a href="http://www.washington.edu"
|
||||
target="_top">University
|
||||
of Washington</a> 1969</li>
|
||||
<li>Burroughs Corporation (now <a href="http://www.unisys.com">Unisys</a>
|
||||
<li>Burroughs Corporation (now <a href="http://www.unisys.com"
|
||||
target="_top">Unisys</a>
|
||||
) 1969 - 1980</li>
|
||||
<li><a href="http://www.tandem.com">Tandem Computers, Incorporated</a>
|
||||
(now part of the <a href="http://www.hp.com">The New HP</a>) 1980 -
|
||||
<li><a href="http://www.tandem.com" target="_top">Tandem Computers,
|
||||
Incorporated</a>
|
||||
(now part of the <a href="http://www.hp.com" target="_top">The New HP</a>)
|
||||
1980 -
|
||||
present</li>
|
||||
<li>Married 1969 - no children.</li>
|
||||
</ul>
|
||||
@ -53,7 +65,8 @@ Seattle Firewall</a>. Expanding on what I learned from Seattle
|
||||
Firewall, I then designed and wrote Shorewall. </p>
|
||||
<p>I telework from our <a
|
||||
href="http://lists.shorewall.net/SeattleInTheSpring.html">home</a>
|
||||
in <a href="http://www.cityofshoreline.com">Shoreline, Washington</a>
|
||||
in <a href="http://www.cityofshoreline.com" target="_top">Shoreline,
|
||||
Washington</a>
|
||||
where
|
||||
I live with my wife Tarry. </p>
|
||||
<p></p>
|
||||
@ -61,7 +74,8 @@ I live with my wife Tarry. </p>
|
||||
</ul>
|
||||
<p>For information about our home network see <a href="myfiles.htm">my
|
||||
Shorewall Configuration files.</a></p>
|
||||
<p>All of our other systems are made by <a href="http://www.compaq.com">Compaq</a>
|
||||
(part of the new <a href="http://www.hp.com/">HP</a>).</p>
|
||||
<p>All of our other systems are made by <a href="http://www.compaq.com"
|
||||
target="_top">Compaq</a>
|
||||
(part of the new <a href="http://www.hp.com/" target="_top">HP</a>).</p>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -42,7 +42,9 @@ Netfilter to match your requirements. Shorewall can be used on a
|
||||
dedicated firewall system, a multi-function gateway/router/server
|
||||
or on a standalone GNU/Linux system. Shorewall does not use
|
||||
Netfilter's ipchains compatibility mode and can thus take advantage
|
||||
of Netfilter's connection state tracking capabilities.
|
||||
of Netfilter's <a
|
||||
href="http://www.cs.princeton.edu/%7Ejns/security/iptables/iptables_conntrack.html">connection
|
||||
state tracking capabilities</a>.
|
||||
<p>This program is free software; you can redistribute it and/or
|
||||
modify it under the terms of <a
|
||||
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU
|
||||
@ -75,6 +77,16 @@ Shorewall. For older versions:<br>
|
||||
target="_top">here</a>.<br>
|
||||
</li>
|
||||
</ul>
|
||||
<h2>Read about</h2>
|
||||
You can <a
|
||||
href="http://lists.shorewall.net/pipermail/shorewall-users/2004-February/011163.html">prepare
|
||||
for 2.0</a> while you are still running Shorewall 1.4.<br>
|
||||
<br>
|
||||
The <a href="http://shorewall.net/pub/shorewall/Beta">Shorewall 2.0.0
|
||||
RC2</a> is available!<br>
|
||||
<br>
|
||||
Here's the <a href="http://shorewall.net/2.0/Documentation_Index.html">Shorewall
|
||||
2.0.0 Documentation</a>.<br>
|
||||
<h2>Getting Started with Shorewall</h2>
|
||||
New to Shorewall? Start by selecting the <a
|
||||
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most
|
||||
@ -85,16 +97,43 @@ The <a href="Documentation_Index.html">Documentation
|
||||
Index</a> is a good place to start as is the Quick Search in the
|
||||
frame above.
|
||||
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
|
||||
If so, the documentation <b></b>on this site will not apply
|
||||
If so, the documentation on this site will not apply
|
||||
directly to your setup. If you want to use the documentation that
|
||||
you find here, you will want to consider uninstalling what you have
|
||||
and installing a setup that matches the documentation on this site.
|
||||
See the <a href="two-interface.htm">Two-interface QuickStart
|
||||
Guide</a> for details.
|
||||
<h2><b>News</b></h2>
|
||||
<p><b>1/30/2004 - Shorewall 1.4.10</b><b> <img alt="(New)"
|
||||
<p><b>2/15/2004 - Shorewall 1.4.10c </b><b> <img alt="(New)"
|
||||
src="images/new10.gif"
|
||||
style="border: 0px solid ; width: 28px; height: 12px;" title=""></b></p>
|
||||
<p>Corrects one problem:<br>
|
||||
</p>
|
||||
Entries in /etc/shorewall/tcrules with an empty USER/GROUP column would
|
||||
cause a startup error.
|
||||
<p><b>2/12/2004 - Shorewall 1.4.10b </b><b> <img alt="(New)"
|
||||
src="images/new10.gif"
|
||||
style="border: 0px solid ; width: 28px; height: 12px;" title=""></b></p>
|
||||
<p>Corrects one problem:<br>
|
||||
</p>
|
||||
<ul>
|
||||
<li>In the /etc/shorewall/masq entry “<span class="quote">eth0:!10.1.1.150
|
||||
0.0.0.0/0!10.1.0.0/16 10.1.2.16</span>”, the
|
||||
“<span class="quote">!10.1.0.0/16</span>” is ignored.</li>
|
||||
</ul>
|
||||
<p><b>2/8/2004 - Shorewall 1.4.10a </b><b> <img alt="(New)"
|
||||
src="images/new10.gif"
|
||||
style="border: 0px solid ; width: 28px; height: 12px;" title=""></b></p>
|
||||
<p>Corrects two problems:<br>
|
||||
</p>
|
||||
<ul>
|
||||
<li>A problem which can cause [re]start to fail inexplicably
|
||||
while processing /etc/shorewall/masq.</li>
|
||||
<li>Interfaces using the Atheros WiFi card to use the 'maclist'
|
||||
option.<br>
|
||||
</li>
|
||||
</ul>
|
||||
<p><b>1/30/2004 - Shorewall 1.4.10</b></p>
|
||||
<p>Problems Corrected since version 1.4.9</p>
|
||||
<ol>
|
||||
<li>The column descriptions in the action.template file did not
|
||||
@ -143,7 +182,7 @@ contain :<br>
|
||||
[<user name or number>]:[<group
|
||||
name or number>]<br>
|
||||
<br>
|
||||
The colon is optionnal when specifying only a user.<br>
|
||||
The colon is optional when specifying only a user.<br>
|
||||
<br>
|
||||
Examples : john: / john / :users /
|
||||
john:users<br>
|
||||
@ -160,7 +199,7 @@ column. The named interface must be UP when Shorewall is [re]started.<br>
|
||||
WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
|
||||
</li>
|
||||
</ol>
|
||||
<p><b>1/17/2004 - FAQ Wiki Available </b><b></b></p>
|
||||
<p><b>1/17/2004 - FAQ Wiki Available </b></p>
|
||||
It has been asserted that the use of CVS for maintaining the
|
||||
Shorewall documentation has been a barrier to community participation.
|
||||
To test this theory, Alex Martin <a
|
||||
@ -275,9 +314,6 @@ these were occuring frequently as a result of a broken system on his
|
||||
external network.</li>
|
||||
</ol>
|
||||
<p><b><a href="News.htm">More News</a></b></p>
|
||||
<b></b>
|
||||
<h2><b></b></h2>
|
||||
<b></b>
|
||||
<p><a href="http://leaf.sourceforge.net" target="_top"><img
|
||||
border="0" src="images/leaflogo.gif" width="49" height="36"
|
||||
alt="(Leaf Logo)"></a> Jacques Nilo and Eric Wolzak have a LEAF
|
||||
@ -290,39 +326,27 @@ Bering 1.2!!!</b> <br>
|
||||
<h1 align="center"><b><a href="http://www.sf.net"><img
|
||||
align="left" alt="SourceForge Logo"
|
||||
src="http://sourceforge.net/sflogo.php?group_id=22587&type=3"></a></b></h1>
|
||||
<b></b>
|
||||
<h4><b></b></h4>
|
||||
<b></b>
|
||||
<h2><b>This site is hosted by the generous folks at <a
|
||||
href="http://www.sf.net">SourceForge.net</a></b></h2>
|
||||
<br>
|
||||
<br>
|
||||
<h2><b><a name="Donations"></a>Donations</b></h2>
|
||||
<b></b></td>
|
||||
<big><img
|
||||
src="file:///vfat/Ursa/Shorewall/Shorewall-Website/images/alz_logo2.gif"
|
||||
title="" alt="(Alzheimer's Association Logo)"
|
||||
style="height: 60px; width: 300px;" align="left"></big><big>Shorewall
|
||||
is free but
|
||||
if you try it and find it useful,
|
||||
please consider making a donation to the <a href="http://www.alz.org/"
|
||||
target="_top">Alzheimer's Association</a>. Thanks!</big><br>
|
||||
<br>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</center>
|
||||
</div>
|
||||
<table border="0" cellpadding="5" cellspacing="0"
|
||||
style="border-collapse: collapse; width: 100%; background-color: rgb(51, 102, 255);"
|
||||
id="AutoNumber2">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td style="width: 100%; margin-top: 1px;">
|
||||
<p align="center"><a href="http://www.starlight.org"><img
|
||||
border="4" src="images/newlog.gif" width="57" height="100" align="left"
|
||||
hspace="10" alt="Starlight Foundation Logo"></a></p>
|
||||
<p align="center"><font size="4" color="#ffffff"><br>
|
||||
<font size="+2">Shorewall is free but if you try it and find it
|
||||
useful, please consider making a donation to <a
|
||||
href="http://www.starlight.org"><font color="#ffffff">Starlight
|
||||
Children's Foundation.</font></a> Thanks!</font></font></p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p><font size="2">Updated 01/30/2004 - <a href="support.htm">Tom
|
||||
<p><font size="2">Updated 03/08/2004 - <a href="support.htm">Tom
|
||||
Eastep</a></font><br>
|
||||
</p>
|
||||
</body>
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-15</pubdate>
|
||||
<pubdate>2004-03-28</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -227,6 +227,16 @@
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><link linkend="Bogons">bogons</link></term>
|
||||
|
||||
<listitem>
|
||||
<para>a parameter file in <filename class="directory">/usr/share/shorewall</filename>
|
||||
used to define the treatment of packets under the <link
|
||||
linkend="Interfaces">nobogons interface option</link>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><link linkend="Routestopped">routestopped</link></term>
|
||||
|
||||
@ -554,18 +564,15 @@ dmz DMZ Demilitarized zone</programlisting>
|
||||
|
||||
<listitem>
|
||||
<para>Packets arriving on this interface and that have a
|
||||
source address that is reserved in RFC 1918 or in other RFCs
|
||||
will be dropped after being optionally logged. If <link
|
||||
linkend="Conf">packet mangling is enabled in
|
||||
<filename>/etc/shorewall/shorewall.conf</filename></link> ,
|
||||
then packets arriving on this interface that have a
|
||||
destination address that is reserved by one of these RFCs will
|
||||
also be logged and dropped.</para>
|
||||
source or destination address that is reserved in RFC 1918
|
||||
will be dropped after being optionally logged.</para>
|
||||
|
||||
<para>Addresses blocked by the standard <link
|
||||
linkend="rfc1918">rfc1918 file</link> include those addresses
|
||||
reserved by RFC1918 plus other ranges reserved by the IANA or
|
||||
by other RFCs.</para>
|
||||
<para>Prior to Shorewall 2.0.1, addresses blocked by the
|
||||
standard <link linkend="rfc1918">rfc1918 file</link> include
|
||||
those addresses reserved by RFC1918 plus other ranges reserved
|
||||
by the IANA or by other RFCs. Beginning with Shorewall 2.0.1,
|
||||
these additional addresses are covered by the <emphasis
|
||||
role="bold">nobogons</emphasis> option below.</para>
|
||||
|
||||
<para>Beware that as IPv4 addresses become in increasingly
|
||||
short supply, ISPs are beginning to use RFC 1918 addresses
|
||||
@ -579,6 +586,17 @@ dmz DMZ Demilitarized zone</programlisting>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>nobogons (Added in Shorewall 2.0.1)</term>
|
||||
|
||||
<listitem>
|
||||
<para>Packets arriving on this interface that have a source
|
||||
address reserved by the IANA or by other RFCs (other than
|
||||
1918) are dropped after being optionally logged. See the
|
||||
/etc/shorewall/bogons file documentation below.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>routefilter</term>
|
||||
|
||||
@ -731,22 +749,32 @@ loc eth1 192.168.1.255,192.168.12.255</programlisting>
|
||||
<term>HOST(S)</term>
|
||||
|
||||
<listitem>
|
||||
<para>The name of a network interface followed by a colon (<quote>:</quote>)
|
||||
followed by a comma-separated list either:</para>
|
||||
<para>The name of an interface defined in the <link
|
||||
linkend="Interfaces">/etc/shorewall/interfaces</link> file followed
|
||||
by a colon (":") and a comma-separated list whose elements
|
||||
are either:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>An IP address (example - eth1:192.168.1.3)</para>
|
||||
<para>The IP address of a host</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A subnet in CIDR notation (example - eth2:192.168.2.0/24)</para>
|
||||
<para>A subnetwork in the form <<emphasis>subnet-address</emphasis>>/<<emphasis>mask
|
||||
width</emphasis>></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>A physical port name (Shorewall version 2.0.1 and later);
|
||||
only allowed when the interface names a bridge created by the
|
||||
<command>brctl addbr </command>command. This port must not be
|
||||
defined in <filename>/etc/shorewall/interfaces</filename> and
|
||||
may optionally followed by a colon (":") and a host or
|
||||
network IP. See the <ulink url="bridge.html">bridging
|
||||
documentation</ulink> for details.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>The interface name much match an entry in
|
||||
<filename>/etc/shorewall/interfaces</filename>.</para>
|
||||
|
||||
<warning>
|
||||
<para>If you are running a version of Shorewall earlier than
|
||||
1.4.6, only a single host/subnet address may be specified in an
|
||||
@ -782,6 +810,69 @@ loc eth1 192.168.1.255,192.168.12.255</programlisting>
|
||||
This option is only valid for ethernet interfaces.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>tcpflags (Added in Shorewall 2.0.1)</term>
|
||||
|
||||
<listitem>
|
||||
<para>(added in version 1.3.11) - This option causes Shorewall
|
||||
to make sanity checks on the header flags in TCP packets
|
||||
arriving from these hosts. Checks include Null flags, SYN+FIN,
|
||||
SYN+RST and FIN+URG+PSH; these flag combinations are typically
|
||||
used for <quote>silent</quote> port scans. Packets failing
|
||||
these checks are logged according to the TCP_FLAGS_LOG_LEVEL
|
||||
option in <xref linkend="Conf" /> and are disposed of
|
||||
according to the TCP_FLAGS_DISPOSITION option.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>blacklist (Added in Shorewall 2.0.1 -- only makes sense
|
||||
for bridge ports)</term>
|
||||
|
||||
<listitem>
|
||||
<para>This option causes incoming packets on this port to be
|
||||
checked against the <link linkend="Blacklist">blacklist</link>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>norfc1918 (Added in Shorewall 2.0.1 -- only makes sense
|
||||
for bridge ports)</term>
|
||||
|
||||
<listitem>
|
||||
<para>Packets arriving on this port and that have a source
|
||||
address that is reserved in RFC 1918 will be dropped after
|
||||
being optionally logged as specified in the settion of
|
||||
RFC1918_LOG_LEVEL in shorewall.conf.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>nobogons (Added in Shorewall 2.0.1 -- only makes sense for
|
||||
bridge ports)</term>
|
||||
|
||||
<listitem>
|
||||
<para>Packets arriving on this port that have a source address
|
||||
reserved by the IANA or by other RFCs (other than 1918) are
|
||||
dropped after being optionally logged. See the
|
||||
/etc/shorewall/bogons file documentation below.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>nosmurfs (Added in Shorewall 2.0.1 -- only makes sense for
|
||||
bridge ports)</term>
|
||||
|
||||
<listitem>
|
||||
<para>If this option is specified, incoming connection
|
||||
requests will be checked to ensure that they do not have a
|
||||
broadcast or multicast address as their source. Any such
|
||||
packets will be dropped after being optionally logged
|
||||
according to the setting of SMURF_LOG_LEVEL in <link
|
||||
linkend="Conf">/etc/shorewall/shorewall.conf</link>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2138,6 +2229,15 @@ eth0 192.168.12.0/24 206.124.146.177,206.124.146.179</programli
|
||||
<para>This file is used to set the following firewall parameters:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>BRIDGING</term>
|
||||
|
||||
<listitem>
|
||||
<para>(Added at version 2.0.1) - When set to Yes or yes, enables
|
||||
<ulink url="bridge.html">Shorewall Bridging support</ulink>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>SMURF_LOG_LEVEL</term>
|
||||
|
||||
@ -2272,6 +2372,18 @@ eth0 192.168.12.0/24 206.124.146.177,206.124.146.179</programli
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>BOGON_LOG_LEVEL</term>
|
||||
|
||||
<listitem>
|
||||
<para>(Added at version 2.0.1) - This parameter determines the level
|
||||
at which packets logged under the <link linkend="rfc1918"><quote>nobogons</quote>
|
||||
mechanism</link> are logged. The value must be a valid <ulink
|
||||
url="shorewall_logging.html">syslog level</ulink> and if no level is
|
||||
given, then info is assumed.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>TCP_FLAGS_DISPOSITION</term>
|
||||
|
||||
@ -2455,7 +2567,17 @@ eth0 192.168.12.0/24 206.124.146.177,206.124.146.179</programli
|
||||
<example>
|
||||
<title></title>
|
||||
|
||||
<programlisting>LOGRATE=10/minute LOGBURST=5</programlisting>
|
||||
<programlisting>LOGRATE=10/minute
|
||||
LOGBURST=5</programlisting>
|
||||
|
||||
<para>For each logging rule, the first time the rule is reached,
|
||||
the packet will be logged; in fact, since the burst is 5, the
|
||||
first five packets will be logged. After this, it will be 6
|
||||
seconds (1 minute divided by the rate of 10) before a message will
|
||||
be logged from the rule, regardless of how many packets reach it.
|
||||
Also, every 6 seconds which passes without matching a packet, one
|
||||
of the bursts will be regained; if no packets hit the rule for 30
|
||||
seconds, the burst will be fully recharged; back where we started.</para>
|
||||
</example>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -2907,6 +3029,116 @@ all all tcp ftp-data - 8</programlisting
|
||||
modify the copy.</para>
|
||||
</section>
|
||||
|
||||
<section id="Bogons" xreflabel="/etc/shorewall/rfc1918">
|
||||
<title>/usr/share//shorewall/bogons — Added in Version 2.0.1</title>
|
||||
|
||||
<para>This file lists the subnets affected by the <link
|
||||
linkend="Interfaces">nobogons interface option</link> and <link
|
||||
linkend="Hosts">nobogons hosts option</link>. Columns in the file are:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>SUBNET</term>
|
||||
|
||||
<listitem>
|
||||
<para>The subnet using VLSM notation (e.g., 192.168.0.0/16).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>TARGET</term>
|
||||
|
||||
<listitem>
|
||||
<para>What to do with packets to/from the SUBNET:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>RETURN</term>
|
||||
|
||||
<listitem>
|
||||
<para>Process the packet normally thru the rules and policies.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>DROP</term>
|
||||
|
||||
<listitem>
|
||||
<para>Silently drop the packet.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>logdrop</term>
|
||||
|
||||
<listitem>
|
||||
<para>Log then drop the packet -- see the <link linkend="Conf">BOGONS_LOG_LEVEL</link>
|
||||
parameter above.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>If you want to modify this file, DO NOT MODIFY <filename>/usr/share/shorewall/bogons</filename>.
|
||||
Rather copy that file to <filename>/etc/shorewall/bogons </filename>and
|
||||
modify the copy.</para>
|
||||
</section>
|
||||
|
||||
<section id="Netmap">
|
||||
<title>/etc/shorewall/netmap (Added in Version 2.0.1)</title>
|
||||
|
||||
<para>Network mapping is defined using the <filename>/etc/shorewall/netmap</filename>
|
||||
file. Columns in this file are:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>TYPE</term>
|
||||
|
||||
<listitem>
|
||||
<para>Must be DNAT or SNAT.</para>
|
||||
|
||||
<para>If DNAT, traffic entering INTERFACE and addressed to NET1 has
|
||||
it's destination address rewritten to the corresponding address
|
||||
in NET2.</para>
|
||||
|
||||
<para>If SNAT, traffic leaving INTERFACE with a source address in
|
||||
NET1 has it's source address rewritten to the corresponding
|
||||
address in NET2.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>NET1</term>
|
||||
|
||||
<listitem>
|
||||
<para>Must be expressed in CIDR format (e.g., 192.168.1.0/24).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>INTERFACE</term>
|
||||
|
||||
<listitem>
|
||||
<para>A firewall interface. This interface must have been defined in
|
||||
<ulink url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term>NET2</term>
|
||||
|
||||
<listitem>
|
||||
<para>A second network expressed in CIDR format.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>For more information, see the <ulink url="netmap.html">Network
|
||||
Mapping documentation</ulink>.</para>
|
||||
</section>
|
||||
|
||||
<section id="Routestopped" xreflabel="/etc/shorewall/routestopped">
|
||||
<title>/etc/shorewall/routestopped (Added in Version 1.3.4)</title>
|
||||
|
||||
@ -2968,7 +3200,8 @@ eth1 -</programlisting>
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory><revision><revnumber>1.15</revnumber><date>2004-02-16</date><authorinitials>TE</authorinitials><revremark>Move
|
||||
<para><revhistory><revision><revnumber>1.16</revnumber><date>2004-03-17</date><authorinitials>TE</authorinitials><revremark>Clarified
|
||||
LOGBURST and LOGLIMIT.</revremark></revision><revision><revnumber>1.15</revnumber><date>2004-02-16</date><authorinitials>TE</authorinitials><revremark>Move
|
||||
the rfc1918 file to /usr/share/shorewall.</revremark></revision><revision><revnumber>1.14</revnumber><date>2004-02-13</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
a note about the order of rules.</revremark></revision><revision><revnumber>1.13</revnumber><date>2004-02-03</date><authorinitials>TE</authorinitials><revremark>Update
|
||||
for Shorewall 2.0.</revremark></revision><revision><revnumber>1.12</revnumber><date>2004-01-21</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-15</pubdate>
|
||||
<pubdate>2004-03-28</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -23,7 +23,7 @@
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
|
||||
<edition>2.0.0-Beta1</edition>
|
||||
<edition>2.0.1</edition>
|
||||
|
||||
<legalnotice>
|
||||
<para>Permission is granted to copy, distribute and/or modify this
|
||||
@ -40,10 +40,11 @@
|
||||
url="http://www.mandrakesoft.com"><trademark>Mandrake</trademark> Linux</ulink>
|
||||
with a two-interface setup?</para>
|
||||
|
||||
<para>If so, this documentation will not apply directly to your
|
||||
environment. If you want to use the documentation that you find here, you
|
||||
will want to consider uninstalling what you have and installing a
|
||||
configuration that matches this documentation. See the <ulink
|
||||
<para>If so and if you configured your system while running a Mandrake
|
||||
release earlier than 10.0 final then this documentation will not apply
|
||||
directly to your environment. If you want to use the documentation that
|
||||
you find here, you will want to consider uninstalling what you have and
|
||||
installing a configuration that matches this documentation. See the <ulink
|
||||
url="two-interface.htm">Two-interface QuickStart Guide</ulink> for
|
||||
details.</para>
|
||||
</caution>
|
||||
@ -91,6 +92,10 @@
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="bridge.html">Bridge/Firewall</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="starting_and_stopping_shorewall.htm">Commands</ulink>
|
||||
(Description of all /sbin/shorewall commands)</para>
|
||||
@ -138,7 +143,9 @@
|
||||
url="Accounting.html">accounting</ulink></para></listitem><listitem><para><ulink
|
||||
url="UserSets.html">usersets and users</ulink></para></listitem><listitem><para><ulink
|
||||
url="MAC_Validation.html">maclist</ulink></para></listitem><listitem><para><ulink
|
||||
url="User_defined_Actions.html">actions and action.template</ulink></para></listitem></itemizedlist></para>
|
||||
url="User_defined_Actions.html">actions and action.template</ulink></para></listitem><listitem><para><ulink
|
||||
url="Documentation.htm#Bogons">bogons</ulink></para></listitem><listitem><para><ulink
|
||||
url="Documentation.htm#Netmap">netmap</ulink></para></listitem></itemizedlist></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -228,6 +235,10 @@
|
||||
<para><ulink url="NetfilterOverview.html">Netfilter Overview</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="netmap.html">Network Mapping</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="NAT.htm">One-to-one NAT</ulink> (Formerly referred to
|
||||
as Static NAT)</para>
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-01-22</pubdate>
|
||||
<pubdate>2004-03-20</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -52,24 +52,9 @@
|
||||
configuring FreeS/Wan.</para>
|
||||
|
||||
<warning>
|
||||
<para>Do not use Proxy ARP and FreeS/Wan on the same system unless you
|
||||
are prepared to suffer the consequences. If you start or restart
|
||||
Shorewall with an IPSEC tunnel active, the proxied IP addresses are
|
||||
mistakenly assigned to the IPSEC tunnel device (ipsecX) rather than to
|
||||
the interface that you specify in the INTERFACE column of
|
||||
/etc/shorewall/proxyarp. I haven't had the time to debug this
|
||||
problem so I can't say if it is a bug in the Kernel or in FreeS/Wan.</para>
|
||||
|
||||
<para>You <emphasis role="bold">might</emphasis> be able to work around
|
||||
this problem using the following (I haven't tried it):</para>
|
||||
|
||||
<para>In /etc/shorewall/init, include:</para>
|
||||
|
||||
<programlisting>qt service ipsec stop</programlisting>
|
||||
|
||||
<para>In /etc/shorewall/start, include:</para>
|
||||
|
||||
<programlisting>qt service ipsec start</programlisting>
|
||||
<para>IPSEC and Proxy ARP do not work unless you are running Shorewall
|
||||
2.0.1 Beta 3 or later or unless you have installed the fix to Shorewall
|
||||
2.0.0 available from the <ulink url="errata.htm">Errata Page</ulink>.</para>
|
||||
</warning>
|
||||
|
||||
<important>
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-01-06</pubdate>
|
||||
<pubdate>2004-04-05</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -38,7 +38,7 @@
|
||||
MAC address may be optionally associated with one or more IP addresses.</para>
|
||||
|
||||
<important>
|
||||
<para><emphasis role="bold">MAC addresses are only visible within a
|
||||
<para><emphasis role="bold">MAC addresses are only visible within an
|
||||
ethernet segment so all MAC addresses used in verification must belong to
|
||||
devices physically connected to one of the LANs to which your firewall is
|
||||
connected.</emphasis></para>
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2004-03-05</pubdate>
|
||||
<pubdate>2004-03-18</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003</year>
|
||||
@ -37,12 +37,6 @@
|
||||
<title>Shorewall Cannot:</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Be used to filter traffic through a Layer 2 Bridge (although
|
||||
experimental Shorewall Bridge code is available — check <ulink
|
||||
url="bridge.html">here</ulink> for details).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Act as a <quote>Personal Firewall</quote> that allows internet
|
||||
access by application.</para>
|
||||
@ -80,7 +74,8 @@
|
||||
<listitem>
|
||||
<para>Shorewall does not contain any support for Netfilter <ulink
|
||||
url="http://www.netfilter.org/documentation/pomlist/pom-summary.html">Patch-O-Matic</ulink>
|
||||
features -- Shorewall only supports features from released kernels.</para>
|
||||
features or any other features that require kernel patching --
|
||||
Shorewall only supports features from released kernels.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-04</pubdate>
|
||||
<pubdate>2004-03-29</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003-2004</year>
|
||||
@ -51,8 +51,8 @@
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>In all cases, Squid should be configured to run as a transrent
|
||||
proxy as described at
|
||||
http://tldp.org/HOWTO/mini/TransparentProxy.html.</para>
|
||||
proxy as described at <ulink
|
||||
url="http://tldp.org/HOWTO/mini/TransparentProxy.html">http://tldp.org/HOWTO/mini/TransparentProxy.html</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-03-10</pubdate>
|
||||
<pubdate>2004-03-25</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003</year>
|
||||
@ -230,6 +230,8 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Omitted column entries should be entered using a dash ("-:).</para>
|
||||
|
||||
<para>Example:</para>
|
||||
|
||||
<para><filename>/etc/shorewall/actions</filename>:</para>
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-03-06</pubdate>
|
||||
<pubdate>2004-04-05</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2004</year>
|
||||
@ -68,20 +68,19 @@
|
||||
<section>
|
||||
<title>Requirements</title>
|
||||
|
||||
<para>In order to use Shorewall with a bridging firewall, your kernel must
|
||||
meet the following requirements:</para>
|
||||
<para>In order to use Shorewall with a bridging firewall:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>It must contain bridge support (CONFIG_BRIDGE=m or
|
||||
<para>Your kernel must contain bridge support (CONFIG_BRIDGE=m or
|
||||
CONFIG_BRIDGE=y).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>It must contain Netfilter physdev match support
|
||||
<para>Your kernel must contain Netfilter physdev match support
|
||||
(CONFIG_IP_NF_MATCH_PHYSDEV=m or CONFIG_IP_NF_MATCH_PHYSDEV=y).
|
||||
Physdev match is available in the 2.6 kernel series but must be
|
||||
patched into the 2.4 kernels (see <ulink url="http://bridge.sf.net">http://bridge.sf.net</ulink>).</para>
|
||||
Physdev match is standard in the 2.6 kernel series but must be patched
|
||||
into the 2.4 kernels (see <ulink url="http://bridge.sf.net">http://bridge.sf.net</ulink>).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -93,11 +92,11 @@
|
||||
<para>You must have the bridge utilities (bridge-utils) package
|
||||
installed.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>You must also be running Shorewall 2.0.1 or later (users running
|
||||
Shorewall 2.0.0-RC* or Shorewall-2.0.0 may find the necessary updated
|
||||
files at <ulink url="http://shorewall.net/pub/shorewall/Bridging">http://shorewall.net/pub/shorewall/Bridging</ulink>).</para>
|
||||
<listitem>
|
||||
<para>You must be running Shorewall 2.0.1 Beta 1 or later.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -145,7 +144,9 @@
|
||||
<para>There are other possibilities here -- there could be a hub or switch
|
||||
between the router and the Bridge/Firewall and there could be other
|
||||
systems connected to that switch. All of the systems on the local side of
|
||||
the router would still be configured with IP addresses in 192.168.1.0/24.</para>
|
||||
the <emphasis role="bold">router</emphasis> would still be configured with
|
||||
IP addresses in 192.168.1.0/24 as shown below.<graphic
|
||||
fileref="images/bridge3.png" /></para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -160,11 +161,13 @@
|
||||
configuration tools and the network configuration GUIs don't detect
|
||||
the presence of bridge devices. You may refer to <ulink
|
||||
url="http://shorewall.net/2.0/myfiles.htm">my configuration files</ulink>
|
||||
for an example of configuring a bridge at system boot under
|
||||
for an example of configuring a three-port bridge at system boot under
|
||||
<trademark>SuSE</trademark>. Here is an excerpt from a Debian
|
||||
<filename>/etc/network/interfaces</filename> file for a bridge:</para>
|
||||
<filename>/etc/network/interfaces</filename> file for a two-port bridge
|
||||
with a static IP address:</para>
|
||||
|
||||
<programlisting>auto br0
|
||||
<blockquote>
|
||||
<programlisting>auto br0
|
||||
iface br0 inet static
|
||||
address 192.168.1.253
|
||||
netmask 255.255.255.0
|
||||
@ -174,14 +177,68 @@ iface br0 inet static
|
||||
pre-up /sbin/ip link set eth1 up
|
||||
pre-up /usr/sbin/brctl addbr br0
|
||||
pre-up /usr/sbin/brctl addif br0 eth0
|
||||
pre-up /usr/sbin/brctl addif br0 eth1
|
||||
gateway:/etc/network#</programlisting>
|
||||
pre-up /usr/sbin/brctl addif br0 eth1</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>While it is not a requirement to give the bridge an IP address,
|
||||
doing so allows the bridge/firewall to access other systems and allows the
|
||||
bridge/firewall to be managed remotely. I have not tested Shorewall with a
|
||||
bridge configured without an IP address so if you try it and it
|
||||
doesn't work do not be surprised.</para>
|
||||
bridge/firewall to be managed remotely. The bridge must also have an IP
|
||||
address for REJECT rules and policies to work correctly — otherwise REJECT
|
||||
behaves the same as DROP.</para>
|
||||
|
||||
<para>The bridge may have its IP address assigned via DHCP. Here's an
|
||||
example of an /etc/sysconfig/network/ifcfg-br0 file from a
|
||||
<trademark>SuSE</trademark> system:</para>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>BOOTPROTO='dhcp'
|
||||
REMOTE_IPADDR=''
|
||||
STARTMODE='onboot'
|
||||
UNIQUE='3hqH.MjuOqWfSZ+C'
|
||||
WIRELESS='no'
|
||||
MTU=''</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>Here's an /etc/sysconfig/network-scripts/ifcfg-br0 file for a
|
||||
<trademark>Mandrake</trademark> system:</para>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>DEVICE=br0
|
||||
BOOTPROTO=dhcp
|
||||
ONBOOT=yes</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>On both the SuSE and Mandrake systems, a separate script is required
|
||||
to configure the bridge itself (again see <ulink url="myfiles.htm">my
|
||||
configuration files</ulink> for an example - <filename>/etc/init.d/bridge</filename>).</para>
|
||||
|
||||
<para>Axel Westerhold has contributed this example of configuring a bridge
|
||||
with a static IP address on a Fedora System (Core 1 and Core 2 Test 1).
|
||||
Note that these files also configure the bridge itself so there is no need
|
||||
for a separate bridge config script.</para>
|
||||
|
||||
<blockquote>
|
||||
<para><filename>/etc/sysconfig/network-scripts/ifcfg-br0:</filename></para>
|
||||
|
||||
<programlisting>DEVICE=br0
|
||||
TYPE=Bridge
|
||||
IPADDR=192.168.50.14
|
||||
NETMASK=255.255.255.0
|
||||
ONBOOT=yes</programlisting>
|
||||
|
||||
<para><filename>/etc/sysconfig/network-scripts/ifcfg-eth0:</filename><programlisting>DEVICE=eth0
|
||||
TYPE=ETHER
|
||||
BRIDGE=br0
|
||||
ONBOOT=yes</programlisting><filename>/etc/sysconfig/network-scripts/ifcfg-eth1:</filename><programlisting>DEVICE=eth1
|
||||
TYPE=ETHER
|
||||
BRIDGE=br0
|
||||
ONBOOT=yes</programlisting></para>
|
||||
</blockquote>
|
||||
|
||||
<para>Users who successfully configure bridges on other distributions,
|
||||
with static or dynamic IP addresses, are encouraged to send <ulink
|
||||
url="mailto:webmaster@shorewall.net">me</ulink> their configuration so I
|
||||
can post it here.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -260,7 +317,7 @@ br0 192.168.1.0/24 routeback
|
||||
<listitem>
|
||||
<para>The <filename>/etc/shorewall/interfaces</filename> file is as
|
||||
follows:<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
||||
- br0 detect rfc1918,routefilter
|
||||
- br0 detect routefilter
|
||||
loc eth1 detect</programlisting></para>
|
||||
</listitem>
|
||||
|
||||
@ -277,7 +334,7 @@ dmz br0:eth2</programlisting>
|
||||
<section>
|
||||
<title>Limitations</title>
|
||||
|
||||
<para>Bridging doesn' t work with some wireless cards — see <ulink
|
||||
<para>Bridging doesn' t work with wireless cards — see <ulink
|
||||
url="http://bridge.sf.net">http://bridge.sf.net</ulink>.</para>
|
||||
</section>
|
||||
</article>
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-20</pubdate>
|
||||
<pubdate>2004-04-03</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -82,7 +82,15 @@
|
||||
your own actions for rules in /etc/shorewall/rules (shorewall 1.4.9 and
|
||||
later).</para></listitem><listitem><para><filename>/usr/share/shorewall/actions.std</filename>
|
||||
- Actions defined by Shorewall.</para></listitem><listitem><para><filename>/usr/share/shorewall/actions.*</filename>
|
||||
- Details of actions defined by Shorewall.</para></listitem></itemizedlist></para>
|
||||
- Details of actions defined by Shorewall.</para></listitem><listitem><para><filename>/usr/share/rfc1918</filename>
|
||||
— Defines the behavior of the 'norfc1918' interface option in
|
||||
<filename>/etc/shorewall/interfaces</filename>. <emphasis role="bold">If
|
||||
you need to change this file, copy it to <filename>/etc/shorewall</filename>
|
||||
and modify the copy</emphasis>.</para></listitem><listitem><para><filename>/usr/share/bogons</filename>
|
||||
— Defines the behavior of the 'nobogons' interface option in
|
||||
<filename>/etc/shorewall/interfaces</filename>. <emphasis role="bold">If
|
||||
you need to change this file, copy it to <filename>/etc/shorewall</filename>
|
||||
and modify the copy</emphasis>.</para></listitem></itemizedlist></para>
|
||||
</section>
|
||||
|
||||
<section id="Comments">
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-03-15</pubdate>
|
||||
<pubdate>2004-03-20</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -67,7 +67,12 @@
|
||||
|
||||
<para><ulink url="http://shorewall.net/pub/shorewall/errata/1.4.8/rfc1918">Here</ulink>
|
||||
is the most up to date version of the <ulink
|
||||
url="Documentation.htm#rfc1918">rfc1918 file</ulink>.</para>
|
||||
url="Documentation.htm#rfc1918">rfc1918 file</ulink>. This file only
|
||||
applies to Shorewall version 2.0.0 and its bugfix updates. In Shorewall
|
||||
2.0.1 and later releases, the <filename>bogons</filename> file lists IP
|
||||
ranges that are reserved by the IANA and the <filename>rfc1918</filename>
|
||||
file only lists those three ranges that are reserved by <ulink
|
||||
url="shorewall_setup_guide.htm#RFC1918">RFC 1918</ulink>.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -81,12 +86,20 @@
|
||||
<para>When using an Action in the ACTIONS column of a rule, you may
|
||||
receive a warning message about the rule being a policy. While this
|
||||
warning may be safely ignored, it can be eliminated by installing
|
||||
<ulink
|
||||
url="http://shorewall.net/pub/shorewall/errata/2.0.0/firewall">this
|
||||
corrected firewall script</ulink> in /usr/share/shorewall as
|
||||
described above.</para>
|
||||
the script from the link below.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Thanks to Sean Mathews, a long-standing problem with Proxy ARP
|
||||
and IPSEC has been corrected.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>The first problem has been corrected in Shorewall update 2.0.0a.</para>
|
||||
|
||||
<para>All of these problems may be corrected by installing <ulink
|
||||
url="http://shorewall.net/pub/shorewall/errata/2.0.0/firewall">this
|
||||
firewall script</ulink> in /usr/share/shorewall as described above.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@ -230,7 +243,9 @@ Aborted (core dumped)</programlisting>
|
||||
<appendix>
|
||||
<title>Revision History4</title>
|
||||
|
||||
<para><revhistory><revision><revnumber>1.5</revnumber><date>2004-02-03</date><authorinitials>TE</authorinitials><revremark>Update
|
||||
<para><revhistory><revision><revnumber>1.6</revnumber><date>2004-03-20</date><authorinitials>TE</authorinitials><revremark>Proxy
|
||||
ARP/IPSEC fix.</revremark></revision><revision><revnumber>1.6</revnumber><date>2004-03-17</date><authorinitials>TE</authorinitials><revremark>Action
|
||||
rules are reported as policies.</revremark></revision><revision><revnumber>1.5</revnumber><date>2004-02-03</date><authorinitials>TE</authorinitials><revremark>Update
|
||||
for Shorewall 2.0.0.</revremark></revision><revision><revnumber>1.4</revnumber><date>2004-01-19</date><authorinitials>TE</authorinitials><revremark>IPV6
|
||||
address problems. Make RFC1918 file section more prominent.</revremark></revision><revision><revnumber>1.3</revnumber><date>2004-01-14</date><authorinitials>TE</authorinitials><revremark>Confusing
|
||||
template file in 1.4.9</revremark></revision><revision><revnumber>1.3</revnumber><date>2004-01-03</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
|
||||
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-03-16</pubdate>
|
||||
<pubdate>2004-04-03</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -135,8 +135,7 @@
|
||||
/etc/network/interfaces file (see below) adds a host route to
|
||||
206.124.146.177 through eth1 when that interface is brought up.</para>
|
||||
|
||||
<para>Ursa (192.168.1.5 A.K.A. 206.124.146.178) runs a PPTP server for
|
||||
Road Warrior access.</para>
|
||||
<para>Tarry (192.168.1.4) runs a PPTP server for Road Warrior access.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -464,8 +463,8 @@ Mirrors net dmz tcp
|
||||
#
|
||||
# When I'm "on the road", the following two rules allow me VPN access back home.
|
||||
#
|
||||
ACCEPT net loc:192.168.1.5 tcp 1723
|
||||
ACCEPT net loc:192.168.1.5 gre
|
||||
DNAT net loc:192.168.1.4 tcp 1723
|
||||
DNAT net loc:192.168.1.4 gre
|
||||
#
|
||||
# ICQ
|
||||
#
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-18</pubdate>
|
||||
<pubdate>2004-03-27</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2002</year>
|
||||
@ -40,35 +40,41 @@
|
||||
</abstract>
|
||||
</articleinfo>
|
||||
|
||||
<note>
|
||||
<para>Beginning with Shorewall 2.0.0, the Shorewall distribution contains
|
||||
a library of user-defined actions that allow for easily allowing or
|
||||
blocking a particular application. Check your <filename>/etc/shorewall/actions.std</filename>
|
||||
file for a list of the actions in your distribution. If you find what you
|
||||
need, you simply use the action in a rule. For example, to allow DNS
|
||||
queries from the <emphasis role="bold">dmz</emphasis> zone to the
|
||||
<emphasis role="bold">net</emphasis> zone:</para>
|
||||
<section>
|
||||
<title>Important Notes</title>
|
||||
|
||||
<programlisting>#ACTION SOURCE DESTINATION
|
||||
AllowPing dmz net</programlisting>
|
||||
</note>
|
||||
<note>
|
||||
<para>Beginning with Shorewall 2.0.0, the Shorewall distribution
|
||||
contains a library of user-defined actions that allow for easily
|
||||
allowing or blocking a particular application. Check your
|
||||
<filename>/etc/shorewall/actions.std</filename> file for a list of the
|
||||
actions in your distribution. If you find what you need, you simply use
|
||||
the action in a rule. For example, to allow DNS queries from the
|
||||
<emphasis role="bold">dmz</emphasis> zone to the <emphasis role="bold">net</emphasis>
|
||||
zone:</para>
|
||||
|
||||
<note>
|
||||
<para>In the rules that are shown in this document, the ACTION is shown as
|
||||
ACCEPT. You may need to use DNAT (see <ulink url="FAQ.htm#faq30">FAQ 30</ulink>)
|
||||
or you may want DROP or REJECT if you are trying to block the application.</para>
|
||||
<programlisting>#ACTION SOURCE DESTINATION
|
||||
AllowDNS dmz net</programlisting>
|
||||
</note>
|
||||
|
||||
<para>Example: You want to port forward FTP from the net to your server at
|
||||
192.168.1.4 in your DMZ. The FTP section below gives you:</para>
|
||||
<note>
|
||||
<para>In the rules that are shown in this document, the ACTION is shown
|
||||
as ACCEPT. You may need to use DNAT (see <ulink url="FAQ.htm#faq30">FAQ
|
||||
30</ulink>) or you may want DROP or REJECT if you are trying to block
|
||||
the application.</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
<para>Example: You want to port forward FTP from the net to your server
|
||||
at 192.168.1.4 in your DMZ. The FTP section below gives you:</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <emphasis><source></emphasis> <emphasis><destination></emphasis> tcp 21</programlisting>
|
||||
|
||||
<para>You would code your rule as follows:</para>
|
||||
<para>You would code your rule as follows:</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
DNAT net dmz:192.168.1.4 tcp 21</programlisting>
|
||||
</note>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Auth (identd)</title>
|
||||
|
||||
@ -13,11 +13,13 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2003-07-01</pubdate>
|
||||
<pubdate>2004-03-28</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003</year>
|
||||
|
||||
<year>2004</year>
|
||||
|
||||
<holder>Thomas M Eastep</holder>
|
||||
</copyright>
|
||||
|
||||
@ -46,6 +48,17 @@
|
||||
grateful</emphasis></para>
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<attribution>SE, California, USA</attribution>
|
||||
|
||||
<para><emphasis>In two words, I'd call Shorewall "brilliant
|
||||
simplicity". Define general rules of what it is you want to do, and
|
||||
let the software determine the specific rules on how to implement it.
|
||||
It's great only having to define specific rules for specific
|
||||
instances. I have a much higher degree of confidence in my firewall than
|
||||
I have had previously. Thank you for Shorewall!.</emphasis></para>
|
||||
</blockquote>
|
||||
|
||||
<blockquote>
|
||||
<attribution>BC, USA</attribution>
|
||||
|
||||
|
||||
@ -13,10 +13,10 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2003-11-13</pubdate>
|
||||
<pubdate>2004-04-04</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2003</year>
|
||||
<year>2001-2004</year>
|
||||
|
||||
<holder>Thomas M Eastep</holder>
|
||||
</copyright>
|
||||
@ -82,7 +82,8 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Extensive <ulink url="Documentation_Index.html">documentation</ulink>
|
||||
<para>Extensive <emphasis role="bold"><ulink
|
||||
url="Documentation_Index.html">documentation</ulink></emphasis>
|
||||
included in the .tgz and .rpm downloads.</para>
|
||||
</listitem>
|
||||
|
||||
@ -110,8 +111,9 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink role="bold" url="blacklisting_support.htm">Blacklisting</ulink>
|
||||
of individual IP addresses and subnetworks is supported.</para>
|
||||
<para><ulink role="bold" url="blacklisting_support.htm"><emphasis
|
||||
role="bold">Blacklisting</emphasis></ulink> of individual IP addresses
|
||||
and subnetworks is supported.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -150,8 +152,9 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Support for <ulink url="traffic_shaping.htm">Traffic
|
||||
Control/Shaping</ulink> integration.</para>
|
||||
<para>Support for <ulink url="traffic_shaping.htm"><emphasis
|
||||
role="bold">Traffic</emphasis> Control/<emphasis role="bold">Shaping</emphasis></ulink>
|
||||
integration.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -180,12 +183,18 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="MAC_Validation.html">Media Access Control (MAC)
|
||||
Address Verification</ulink>.</para>
|
||||
<para><ulink url="MAC_Validation.html">Media Access Control (<emphasis
|
||||
role="bold">MAC</emphasis>) Address <emphasis role="bold">Verification</emphasis></ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="Accounting.html">Traffic Accounting</ulink>.</para>
|
||||
<para><emphasis role="bold"><ulink url="Accounting.html">Traffic
|
||||
Accounting</ulink>.</emphasis></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="bridge.html"><emphasis role="bold">Bridge</emphasis>/Firewall
|
||||
support</ulink> (requires a 2.6 kernel or a patched 2.4 kernel).</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-04</pubdate>
|
||||
<pubdate>2004-04-03</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -2211,6 +2211,61 @@ foobar.net. 86400 IN A 192.0.2.177
|
||||
86400 IN MX 1 <backup MX>.</programlisting>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Some Things to Keep in Mind</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">You cannot test your firewall from the
|
||||
inside</emphasis>. Just because you send requests to your firewall
|
||||
external IP address does not mean that the request will be associated
|
||||
with the external interface or the <quote>net</quote> zone. Any
|
||||
traffic that you generate from the local network will be associated
|
||||
with your local interface and will be treated as loc->fw traffic.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">IP addresses are properties of systems,
|
||||
not of interfaces</emphasis>. It is a mistake to believe that your
|
||||
firewall is able to forward packets just because you can ping the IP
|
||||
address of all of the firewall's interfaces from the local
|
||||
network. The only conclusion you can draw from such pinging success is
|
||||
that the link between the local system and the firewall works and that
|
||||
you probably have the local system's default gateway set
|
||||
correctly.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">All IP addresses configured on firewall
|
||||
interfaces are in the $FW (fw) zone</emphasis>. If 192.168.1.254 is
|
||||
the IP address of your internal interface then you can write
|
||||
<quote><emphasis role="bold">$FW:192.168.1.254</emphasis></quote> in a
|
||||
rule but you may not write <quote><emphasis role="bold">loc:192.168.1.254</emphasis></quote>.
|
||||
Similarly, it is nonsensical to add 192.168.1.254 to the <emphasis
|
||||
role="bold">loc</emphasis> zone using an entry in
|
||||
<filename>/etc/shorewall/hosts</filename>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Reply packets do NOT automatically follow
|
||||
the reverse path of the one taken by the original request</emphasis>.
|
||||
All packets are routed according to the routing table of the host at
|
||||
each step of the way. This issue commonly comes up when people install
|
||||
a Shorewall firewall parallel to an existing gateway and try to use
|
||||
DNAT through Shorewall without changing the default gateway of the
|
||||
system receiving the forwarded requests. Requests come in through the
|
||||
Shorewall firewall where the destination IP address gets rewritten but
|
||||
replies go out unmodified through the old gateway.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Shorewall itself has no notion of inside
|
||||
or outside</emphasis>. These concepts are embodied in how Shorewall is
|
||||
configured.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section id="StartingAndStopping">
|
||||
<title>Starting and Stopping the Firewall</title>
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-02-12</pubdate>
|
||||
<pubdate>2004-04-03</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2002-2004</year>
|
||||
@ -633,7 +633,7 @@ DNAT loc dmz:10.10.11.2 tcp 80 - $ETH0_IP</pr
|
||||
your primary and secondary name servers. It is your responsibility to
|
||||
configure the resolver in your internal systems. You can take one of two
|
||||
approaches: <itemizedlist><listitem><para>You can configure your internal
|
||||
systems to use your ISP's name servers. If you ISP gave you the
|
||||
systems to use your ISP's name servers. If your ISP gave you the
|
||||
addresses of their servers or if those addresses are available on their
|
||||
web site, you can configure your internal systems to use those addresses.
|
||||
If that information isn't available, look in <filename>/etc/resolv.conf</filename>
|
||||
@ -751,6 +751,61 @@ ACCEPT net fw tcp 80 </programlisting><it
|
||||
remove other connections as required.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Some Things to Keep in Mind</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">You cannot test your firewall from the
|
||||
inside</emphasis>. Just because you send requests to your firewall
|
||||
external IP address does not mean that the request will be associated
|
||||
with the external interface or the <quote>net</quote> zone. Any
|
||||
traffic that you generate from the local network will be associated
|
||||
with your local interface and will be treated as loc->fw traffic.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">IP addresses are properties of systems,
|
||||
not of interfaces</emphasis>. It is a mistake to believe that your
|
||||
firewall is able to forward packets just because you can ping the IP
|
||||
address of all of the firewall's interfaces from the local
|
||||
network. The only conclusion you can draw from such pinging success is
|
||||
that the link between the local system and the firewall works and that
|
||||
you probably have the local system's default gateway set
|
||||
correctly.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">All IP addresses configured on firewall
|
||||
interfaces are in the $FW (fw) zone</emphasis>. If 192.168.1.254 is
|
||||
the IP address of your internal interface then you can write
|
||||
<quote><emphasis role="bold">$FW:192.168.1.254</emphasis></quote> in a
|
||||
rule but you may not write <quote><emphasis role="bold">loc:192.168.1.254</emphasis></quote>.
|
||||
Similarly, it is nonsensical to add 192.168.1.254 to the <emphasis
|
||||
role="bold">loc</emphasis> zone using an entry in
|
||||
<filename>/etc/shorewall/hosts</filename>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Reply packets do NOT automatically follow
|
||||
the reverse path of the one taken by the original request</emphasis>.
|
||||
All packets are routed according to the routing table of the host at
|
||||
each step of the way. This issue commonly comes up when people install
|
||||
a Shorewall firewall parallel to an existing gateway and try to use
|
||||
DNAT through Shorewall without changing the default gateway of the
|
||||
system receiving the forwarded requests. Requests come in through the
|
||||
Shorewall firewall where the destination IP address gets rewritten but
|
||||
replies go out unmodified through the old gateway.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Shorewall itself has no notion of inside
|
||||
or outside</emphasis>. These concepts are embodied in how Shorewall is
|
||||
configured.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Starting and Stopping Your Firewall</title>
|
||||
|
||||
@ -763,11 +818,11 @@ ACCEPT net fw tcp 80 </programlisting><it
|
||||
you have completed configuration of your firewall, you can enable
|
||||
Shorewall startup by removing the file <filename>/etc/shorewall/startup_disabled</filename>.
|
||||
<important><para>Users of the <filename>.deb</filename> package must edit
|
||||
<filename>/etc/default/shorewall</filename> and set <varname>startup=1</varname>.</para></important>
|
||||
The firewall is started using the <command>shorewall start</command>
|
||||
command and stopped using <command>shorewall stop</command>. When the
|
||||
firewall is stopped, routing is enabled on those hosts that have an entry
|
||||
in <ulink url="Documentation.htm#Routestopped"><filename>/etc/shorewall/routestopped</filename></ulink>.
|
||||
<filename>/etc/default/shorewall</filename> and set <varname>startup=1</varname>.</para></important>The
|
||||
firewall is started using the <command>shorewall start</command> command
|
||||
and stopped using <command>shorewall stop</command>. When the firewall is
|
||||
stopped, routing is enabled on those hosts that have an entry in <ulink
|
||||
url="Documentation.htm#Routestopped"><filename>/etc/shorewall/routestopped</filename></ulink>.
|
||||
A running firewall may be restarted using the <command>shorewall restart</command>
|
||||
command. If you want to totally remove any trace of Shorewall from your
|
||||
Netfilter configuration, use <command>shorewall clear</command>.</para>
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2004-02-02</pubdate>
|
||||
<pubdate>2004-04-03</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -143,6 +143,17 @@ iptables: No chain/target/match by that name
|
||||
correctly.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">All IP addresses configured on firewall
|
||||
interfaces are in the $FW (fw) zone</emphasis>. If 192.168.1.254 is
|
||||
the IP address of your internal interface then you can write
|
||||
<quote><emphasis role="bold">$FW:192.168.1.254</emphasis></quote> in a
|
||||
rule but you may not write <quote><emphasis role="bold">loc:192.168.1.254</emphasis></quote>.
|
||||
Similarly, it is nonsensical to add 192.168.1.254 to the <emphasis
|
||||
role="bold">loc</emphasis> zone using an entry in
|
||||
<filename>/etc/shorewall/hosts</filename>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Reply packets do NOT automatically follow
|
||||
the reverse path of the one taken by the original request</emphasis>.
|
||||
@ -158,7 +169,7 @@ iptables: No chain/target/match by that name
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Shorewall itself has no notion of inside
|
||||
or outside</emphasis>. These concepts are embodied in how Shorewall is
|
||||
configured. </para>
|
||||
configured.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
@ -399,7 +410,8 @@ DROP net fw icmp echo-request</programlist
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory><revision><revnumber>1.7</revnumber><date>2005-02-02</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
<para><revhistory><revision><revnumber>1.8</revnumber><date>2005-04-03</date><authorinitials>TE</authorinitials><revremark>Point
|
||||
out that firewall addresses are in the $FW zone.</revremark></revision><revision><revnumber>1.7</revnumber><date>2005-02-02</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
hint about testing from inside the firewall.</revremark></revision><revision><revnumber>1.6</revnumber><date>2005-01-06</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
pointer to Site and Mailing List Archives Searches.</revremark></revision><revision><revnumber>1.5</revnumber><date>2004-01-01</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
information about eliminating ping-generated log messages.</revremark></revision><revision><revnumber>1.4</revnumber><date>2003-12-22</date><authorinitials>TE</authorinitials><revremark>Initial
|
||||
|
||||
@ -12,7 +12,7 @@
|
||||
<surname>Eastep</surname>
|
||||
</author>
|
||||
|
||||
<pubdate>2003-03-16</pubdate>
|
||||
<pubdate>2003-04-03</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2002</year>
|
||||
@ -499,7 +499,7 @@ DNAT net loc:10.10.10.2:80 tcp 5000</programlisting></listite
|
||||
firewall, it is your responsibility to configure the resolver in your
|
||||
internal systems. You can take one of two approaches: <itemizedlist
|
||||
spacing="compact"><listitem><para>You can configure your internal systems
|
||||
to use your ISP's name servers. If you ISP gave you the addresses of
|
||||
to use your ISP's name servers. If your ISP gave you the addresses of
|
||||
their servers or if those addresses are available on their web site, you
|
||||
can configure your internal systems to use those addresses. If that
|
||||
information isn't available, look in /etc/resolv.conf on your firewall
|
||||
@ -586,6 +586,61 @@ ACCEPT loc fw tcp 80 #Allow Weblet to work</progra
|
||||
file to add or delete other connections as required.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Some Things to Keep in Mind</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">You cannot test your firewall from the
|
||||
inside</emphasis>. Just because you send requests to your firewall
|
||||
external IP address does not mean that the request will be associated
|
||||
with the external interface or the <quote>net</quote> zone. Any
|
||||
traffic that you generate from the local network will be associated
|
||||
with your local interface and will be treated as loc->fw traffic.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">IP addresses are properties of systems,
|
||||
not of interfaces</emphasis>. It is a mistake to believe that your
|
||||
firewall is able to forward packets just because you can ping the IP
|
||||
address of all of the firewall's interfaces from the local
|
||||
network. The only conclusion you can draw from such pinging success is
|
||||
that the link between the local system and the firewall works and that
|
||||
you probably have the local system's default gateway set
|
||||
correctly.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">All IP addresses configured on firewall
|
||||
interfaces are in the $FW (fw) zone</emphasis>. If 192.168.1.254 is
|
||||
the IP address of your internal interface then you can write
|
||||
<quote><emphasis role="bold">$FW:192.168.1.254</emphasis></quote> in a
|
||||
rule but you may not write <quote><emphasis role="bold">loc:192.168.1.254</emphasis></quote>.
|
||||
Similarly, it is nonsensical to add 192.168.1.254 to the <emphasis
|
||||
role="bold">loc</emphasis> zone using an entry in
|
||||
<filename>/etc/shorewall/hosts</filename>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Reply packets do NOT automatically follow
|
||||
the reverse path of the one taken by the original request</emphasis>.
|
||||
All packets are routed according to the routing table of the host at
|
||||
each step of the way. This issue commonly comes up when people install
|
||||
a Shorewall firewall parallel to an existing gateway and try to use
|
||||
DNAT through Shorewall without changing the default gateway of the
|
||||
system receiving the forwarded requests. Requests come in through the
|
||||
Shorewall firewall where the destination IP address gets rewritten but
|
||||
replies go out unmodified through the old gateway.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Shorewall itself has no notion of inside
|
||||
or outside</emphasis>. These concepts are embodied in how Shorewall is
|
||||
configured.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Starting and Stopping Your Firewall</title>
|
||||
|
||||
|
||||
@ -60,6 +60,32 @@
|
||||
command to see the groups associated with each of your zones.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 2.0.1</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>The function of 'norfc1918' is now split between that
|
||||
option and a new 'nobogons' option. The rfc1918 file released
|
||||
with Shorewall now contains entries for only those three address
|
||||
ranges reserved by RFC 1918. A 'nobogons' interface option has
|
||||
been added which handles bogon source addresses (those which are
|
||||
reserved by the IANA, those reserved for DHCP auto-configuration and
|
||||
the class C test-net reserved for testing and documentation examples).
|
||||
This will allow users to perform RFC 1918 filtering without having to
|
||||
deal with out of date data from IANA. Those who are willing to update
|
||||
their <filename>/usr/share/shorewall/bogons</filename> file regularly
|
||||
can specify the 'nobogons' option in addition to
|
||||
'norfc1918'. The level at which bogon packets are logged is
|
||||
specified in the new BOGON_LOG_LEVEL variable in shorewall.conf. If
|
||||
that option is not specified or is specified as empty (e.g,
|
||||
BOGON_LOG_LEVEL="") then bogon packets whose TARGET is
|
||||
'logdrop' in <filename>/usr/share/shorewall/bogons</filename>
|
||||
are logged at the 'info' level.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>VERSION >= 2.0.0-Beta1</title>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user