forked from extern/shorewall_code
Shorewall 2.0.2
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1326 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
659ace14da
commit
9def7cde17
@ -42,6 +42,15 @@
|
||||
# to a separate log through use of ulogd
|
||||
# (http://www.gnumonks.org/projects/ulogd).
|
||||
#
|
||||
# Actions specifying logging may be followed by a
|
||||
# log tag (a string of alphanumeric characters)
|
||||
# are appended to the string generated by the
|
||||
# LOGPREFIX (in /etc/shorewall/shorewall.conf).
|
||||
#
|
||||
# Example: ACCEPT:info:ftp would include 'ftp '
|
||||
# at the end of the log prefix generated by the
|
||||
# LOGPREFIX setting.
|
||||
#
|
||||
# SOURCE Source hosts to which the rule applies.
|
||||
# A comma-separated list of subnets
|
||||
# and/or hosts. Hosts may be specified by IP or MAC
|
||||
|
||||
@ -46,13 +46,19 @@
|
||||
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
|
||||
71.0.0.0/8 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
|
||||
89.0.0.0/8 logdrop # Reserved
|
||||
90.0.0.0/7 logdrop # Reserved
|
||||
92.0.0.0/6 logdrop # Reserved
|
||||
96.0.0.0/3 logdrop # Reserved
|
||||
127.0.0.0/8 logdrop # Loopback
|
||||
173.0.0.0/8 logdrop # Reserved
|
||||
174.0.0.0/7 logdrop # Reserved
|
||||
176.0.0.0/5 logdrop # Reserved
|
||||
184.0.0.0/6 logdrop # Reserved
|
||||
189.0.0.0/8 logdrop # Reserved
|
||||
190.0.0.0/8 logdrop # Reserved
|
||||
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
|
||||
|
||||
@ -1,52 +1,61 @@
|
||||
Changes since 2.0.0
|
||||
Changes since 2.0.1
|
||||
|
||||
1) Eliminate Warning about Policy as rule when using actions.
|
||||
1) Reformat the code in define_firewall().
|
||||
|
||||
2) Add bridging Code.
|
||||
2) Reimplement dynamic zones.
|
||||
|
||||
3) Cleanup Warning elimination.
|
||||
3) Tweak new dynamic zone implementation.
|
||||
|
||||
4) Add 'nobogons'
|
||||
4) Implement CONFIG_PATH.
|
||||
|
||||
5) Add 'netmap'
|
||||
5) Apply Stijn Jonker's fix for CONFIG_PATH.
|
||||
|
||||
6) Fix another <zone>_frwd problem.
|
||||
6) Restore logic to make 'find_file' check for SHOREWALL_DIR separately.
|
||||
|
||||
7) Add -x option to /sbin/shorewall.
|
||||
7) Allow CONFIG_PATH to be inherited.
|
||||
|
||||
8) Implement Sean Mathews's fix fix Proxy ARP and IPSEC.
|
||||
8) Fix ensure_config_path call.
|
||||
|
||||
9) Improve zone-definition checking.
|
||||
9) Make LOCAL and ALL INTERFACES independent in the nat file.
|
||||
|
||||
10) Add additional options to hosts file
|
||||
10) Add "ko.gz" to the vast list of module suffixes that distributions
|
||||
have invented.
|
||||
|
||||
11) Replace 'subnet' with 'network' in the code
|
||||
11) Update the bogons file
|
||||
|
||||
12) Fix item 10 above :-(
|
||||
12) Added example for log rate limiting knobs in shorewall.conf.
|
||||
|
||||
13) Replace good code with crap to satisfy 'ash'.
|
||||
13) Fix init.debian.sh.
|
||||
|
||||
14) Fix if_match to only do wild-card matches on patterns ending in
|
||||
"+".
|
||||
14) Implement the -q option.
|
||||
|
||||
15) Tighten edits on bridge port names.
|
||||
15) Add saved configuration support (iptables-save/iptables-restore
|
||||
integration).
|
||||
|
||||
16) Make 'routeback' on interfaces work again.
|
||||
16) Use modprobe if it is available.
|
||||
|
||||
17) Reduce useless intra-zone rules on bridges.
|
||||
17) Lots of fixes to 'save'
|
||||
|
||||
18) Make 'routeback' on hosts work again.
|
||||
18) 'shorewall forget'
|
||||
|
||||
19) Fix display of ICMP packets.
|
||||
19) SNAT/MASQUERADE by proto/port(s)
|
||||
|
||||
20) Fix init.debian.sh
|
||||
20) Shorewall 2.0.2 Beta 1 changes.
|
||||
|
||||
21) Eliminate meaningless warning out of proxyarp processing.
|
||||
21) Fix ALL INTERFACES column parsing.
|
||||
|
||||
22) Fix module loading on Mandrake.
|
||||
22) Correct "shorewall delete" processing.
|
||||
|
||||
23) Eliminate confusing IPV6 warnings.
|
||||
23) Apply Alex Wilms's patch for install.sh
|
||||
|
||||
24) Apply Stefan Engel's fix for "shorewall delete"
|
||||
24) Add ACCEPT+ and NONAT targets.
|
||||
|
||||
25) Apply the install.sh fix from Alex Wilms
|
||||
25) Added 'initialized' extension script.
|
||||
|
||||
26) Renamed 'initialized' to 'initdone'
|
||||
|
||||
27) Applied Stijn Jonker's fix for "shorewall add"
|
||||
|
||||
28) Correct typo that broke "shorewall delete"
|
||||
|
||||
29) Apply Stijn Jonker's -q fix.
|
||||
|
||||
@ -28,7 +28,7 @@
|
||||
# shown below. Simply run this script to revert to your prior version of
|
||||
# Shoreline Firewall.
|
||||
|
||||
VERSION=2.0.1
|
||||
VERSION=2.0.2
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
@ -120,8 +120,12 @@ restore_file /usr/share/shorewall/rfc1918
|
||||
|
||||
restore_file /usr/share/shorewall/bogons
|
||||
|
||||
restore_file /usr/share/shorewall/configpath
|
||||
|
||||
restore_file /etc/shorewall/init
|
||||
|
||||
restore_file /etc/shorewall/initdone
|
||||
|
||||
restore_file /etc/shorewall/start
|
||||
|
||||
restore_file /etc/shorewall/stop
|
||||
|
||||
681
STABLE2/firewall
681
STABLE2/firewall
File diff suppressed because it is too large
Load Diff
@ -82,11 +82,24 @@ fix_bang() {
|
||||
done
|
||||
}
|
||||
|
||||
#
|
||||
# Set default config path
|
||||
#
|
||||
ensure_config_path() {
|
||||
local F=/usr/share/shorewall/configpath
|
||||
if [ -z "$CONFIG_PATH" ]; then
|
||||
[ -f $F ] || { echo " ERROR: $F does not exist"; exit 2; }
|
||||
. $F
|
||||
fi
|
||||
}
|
||||
|
||||
#
|
||||
# Find a File -- For relative file name, look first in $SHOREWALL_DIR then in /etc/shorewall
|
||||
#
|
||||
find_file()
|
||||
{
|
||||
local saveifs= directory
|
||||
|
||||
case $1 in
|
||||
/*)
|
||||
echo $1
|
||||
@ -94,11 +107,19 @@ find_file()
|
||||
*)
|
||||
if [ -n "$SHOREWALL_DIR" -a -f $SHOREWALL_DIR/$1 ]; then
|
||||
echo $SHOREWALL_DIR/$1
|
||||
elif [ -f /etc/shorewall/$1 ]; then
|
||||
echo /etc/shorewall/$1
|
||||
elif [ -f /usr/share/shorewall/$1 ]; then
|
||||
echo /usr/share/shorewall/$1
|
||||
else
|
||||
saveifs=$IFS
|
||||
IFS=:
|
||||
for directory in $CONFIG_PATH; do
|
||||
if [ -f $directory/$1 ]; then
|
||||
echo $directory/$1
|
||||
IFS=$saveifs
|
||||
return
|
||||
fi
|
||||
done
|
||||
|
||||
IFS=$saveifs
|
||||
|
||||
echo /etc/shorewall/$1
|
||||
fi
|
||||
;;
|
||||
@ -485,14 +506,14 @@ in_network() # $1 = IP address, $2 = CIDR network
|
||||
ip_vlsm() {
|
||||
local mask=$(decodeaddr $1)
|
||||
local vlsm=0
|
||||
local x=$(( 128 $LEFTSHIFT 24 ))
|
||||
local x=$(( 128 $LEFTSHIFT 24 )) # 0x80000000
|
||||
|
||||
while [ $(( $x & $mask )) -ne 0 ]; do
|
||||
[ $mask -eq $x ] && mask=0 || mask=$(( $mask $LEFTSHIFT 1 )) # Don't Ask...
|
||||
[ $mask -eq $x ] && mask=0 || mask=$(( $mask $LEFTSHIFT 1 )) # Not all shells shift 0x80000000 left properly.
|
||||
vlsm=$(($vlsm + 1))
|
||||
done
|
||||
|
||||
if [ $(( $mask & 2147483647)) -ne 0 ]; then
|
||||
if [ $(( $mask & 2147483647 )) -ne 0 ]; then # 2147483647 = 0x7fffffff
|
||||
echo "Invalid net mask: $1" >&2
|
||||
else
|
||||
echo $vlsm
|
||||
|
||||
41
STABLE2/help
41
STABLE2/help
@ -116,6 +116,14 @@ drop)
|
||||
See also \"help address\""
|
||||
;;
|
||||
|
||||
forget)
|
||||
echo "forget: forget
|
||||
Deletes /var/lib/shorewall/save and /var/lib/shorewall/restore. Those
|
||||
files are created by the 'shorewall save' command
|
||||
|
||||
See also \"help save\""
|
||||
;;
|
||||
|
||||
help)
|
||||
echo "help: help [<command> | host | address ]
|
||||
Display helpful information about the shorewall commands."
|
||||
@ -157,10 +165,11 @@ monitor)
|
||||
;;
|
||||
|
||||
refresh)
|
||||
echo "refresh: refresh
|
||||
echo "refresh: [ -q ] refresh
|
||||
The rules involving the broadcast addresses of firewall interfaces,
|
||||
the black list, traffic control rules and ECN control rules are recreated
|
||||
to reflect any changes made. Existing connections are untouched"
|
||||
to reflect any changes made. Existing connections are untouched
|
||||
If \"-q\" is specified, less detain is displayed making it easier to spot warnings"
|
||||
;;
|
||||
|
||||
reject)
|
||||
@ -178,15 +187,29 @@ reset)
|
||||
;;
|
||||
|
||||
restart)
|
||||
echo "restart: restart [ -c <configuration-directory> ]
|
||||
echo "restart: restart [ -q ] [ -c <configuration-directory> ]
|
||||
Restart is the same as a shorewall stop && shorewall start.
|
||||
Existing connections are dropped."
|
||||
Existing connections are maintained.
|
||||
If \"-q\" is specified, less detain is displayed making it easier to spot warnings"
|
||||
;;
|
||||
|
||||
restore)
|
||||
echo "restore: restore
|
||||
Restore Shorewall to its last state saved using the 'save' command
|
||||
Existing connections are maintained.
|
||||
|
||||
See also \"help save\" and \"help forget\""
|
||||
;;
|
||||
|
||||
save)
|
||||
echo "save: save
|
||||
The dynamic data is stored in /var/lib/shorewall/save
|
||||
Shorewall allow, drop, rejct and save implement dynamic blacklisting."
|
||||
The dynamic data is stored in /var/lib/shorewall/save. The state of the
|
||||
firewall is stored in /var/lib/shorewall/restore for use by the 'shorewall restore'
|
||||
and 'shorewall -f start' commands.
|
||||
|
||||
Shorewall allow, drop, rejct and save implement dynamic blacklisting.
|
||||
|
||||
See also \"help restore\" and \"help forget\""
|
||||
;;
|
||||
|
||||
show)
|
||||
@ -213,10 +236,12 @@ show)
|
||||
;;
|
||||
|
||||
start)
|
||||
echo "start: start [ -c <configuration-directory> ]
|
||||
echo "start: [ -q ] [ -f ] [ -c <configuration-directory> ] start
|
||||
Start shorewall. Existing connections through shorewall managed
|
||||
interfaces are untouched. New connections will be allowed only
|
||||
if they are allowed by the firewall rules or policies."
|
||||
if they are allowed by the firewall rules or policies.
|
||||
If \"-q\" is specified, less detain is displayed making it easier to spot warnings
|
||||
If \"-f\" is specified, the last saved configuraton if any will be restored"
|
||||
;;
|
||||
|
||||
stop)
|
||||
|
||||
@ -14,6 +14,11 @@
|
||||
# individual IP addresses. Most simple setups don't need to
|
||||
# (should not) place anything in this file.
|
||||
#
|
||||
# The order of entries in this file is not significant in
|
||||
# determining zone composition. Rather, the order that the zones
|
||||
# are defined in /etc/shorewall/zones determines the order in
|
||||
# which the records in this file are interpreted.
|
||||
#
|
||||
# ZONE - The name of a zone defined in /etc/shorewall/zones
|
||||
#
|
||||
# HOST(S) - The name of an interface defined in the
|
||||
@ -49,10 +54,10 @@
|
||||
# an ethernet NIC and must be up before
|
||||
# Shorewall is started.
|
||||
#
|
||||
# routeback - Shorewall show set up the infrastructure
|
||||
# routeback - Shorewall should set up the infrastructure
|
||||
# to pass packets from this/these
|
||||
# address(es) back to themselves. This is
|
||||
# necessary of hosts in this group use the
|
||||
# necessary if hosts in this group use the
|
||||
# services of a transparent proxy that is
|
||||
# a member of the group or if DNAT is used
|
||||
# to send requests originating from this
|
||||
|
||||
@ -83,7 +83,7 @@ wait_for_pppd () {
|
||||
shorewall_start () {
|
||||
echo -n "Starting \"Shorewall firewall\": "
|
||||
wait_for_pppd
|
||||
$SRWL start >> $INITLOG 2>&1 && echo "done." || echo_notdone
|
||||
$SRWL -f start >> $INITLOG 2>&1 && echo "done." || echo_notdone
|
||||
return 0
|
||||
}
|
||||
|
||||
|
||||
@ -62,7 +62,12 @@ command="$1"
|
||||
|
||||
case "$command" in
|
||||
|
||||
stop|start|restart|status)
|
||||
start)
|
||||
|
||||
exec /sbin/shorewall -f start
|
||||
;;
|
||||
|
||||
stop|restart|status)
|
||||
|
||||
exec /sbin/shorewall $@
|
||||
;;
|
||||
|
||||
@ -22,7 +22,7 @@
|
||||
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA
|
||||
#
|
||||
|
||||
VERSION=2.0.1
|
||||
VERSION=2.0.2
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
@ -83,10 +83,12 @@ install_file_with_backup() # $1 = source $2 = target $3 = mode
|
||||
# Parse the run line
|
||||
#
|
||||
# DEST is the SysVInit script directory
|
||||
# INIT is the name of the script in the $DEST directory
|
||||
# RUNLEVELS is the chkconfig parmeters for firewall
|
||||
# ARGS is "yes" if we've already parsed an argument
|
||||
#
|
||||
DEST=""
|
||||
DEST="/etc/init.d"
|
||||
INIT="shorewall"
|
||||
RUNLEVELS=""
|
||||
ARGS=""
|
||||
|
||||
@ -117,10 +119,6 @@ done
|
||||
|
||||
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
|
||||
|
||||
if [ -z "$DEST" ]; then
|
||||
DEST=/etc/init.d
|
||||
fi
|
||||
|
||||
#
|
||||
# Determine where to install the firewall script
|
||||
#
|
||||
@ -160,11 +158,11 @@ echo "shorewall control program installed in ${PREFIX}/sbin/shorewall"
|
||||
if [ -n "$DEBIAN" ]; then
|
||||
install_file_with_backup init.debian.sh /etc/init.d/shorewall 0544
|
||||
else
|
||||
install_file_with_backup init.sh ${PREFIX}${DEST}/shorewall 0544
|
||||
install_file_with_backup init.sh ${PREFIX}${DEST}/$INIT 0544
|
||||
fi
|
||||
|
||||
echo
|
||||
echo "Shorewall script installed in ${PREFIX}${DEST}/shorewall"
|
||||
echo "Shorewall script installed in ${PREFIX}${DEST}/$INIT"
|
||||
|
||||
#
|
||||
# Create /etc/shorewall, /usr/share/shorewall and /var/shorewall if needed
|
||||
@ -392,13 +390,19 @@ fi
|
||||
#
|
||||
install_file_with_backup rfc1918 ${PREFIX}/usr/share/shorewall/rfc1918 0600
|
||||
echo
|
||||
echo "RFC 1918 file installed as ${PREFIX}/etc/shorewall/rfc1918"
|
||||
echo "RFC 1918 file installed as ${PREFIX}/usr/share/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"
|
||||
echo "Bogon file installed as ${PREFIX}/usr/share/shorewall/bogons"
|
||||
#
|
||||
# Install the default config path file
|
||||
#
|
||||
install_file_with_backup configpath ${PREFIX}/usr/share/shorewall/configpath 0600
|
||||
echo
|
||||
echo " Default config path file installed as ${PREFIX}/etc/shorewall/configpath"
|
||||
#
|
||||
# Install the init file
|
||||
#
|
||||
@ -410,6 +414,16 @@ else
|
||||
echo "Init file installed as ${PREFIX}/etc/shorewall/init"
|
||||
fi
|
||||
#
|
||||
# Install the initdone file
|
||||
#
|
||||
if [ -f ${PREFIX}/etc/shorewall/initdone ]; then
|
||||
backup_file /etc/shorewall/initdone
|
||||
else
|
||||
run_install -o $OWNER -g $GROUP -m 0600 initdone ${PREFIX}/etc/shorewall/initdone
|
||||
echo
|
||||
echo "Initdone file installed as ${PREFIX}/etc/shorewall/initdone"
|
||||
fi
|
||||
#
|
||||
# Install the start file
|
||||
#
|
||||
if [ -f ${PREFIX}/etc/shorewall/start ]; then
|
||||
@ -508,7 +522,7 @@ chmod 644 ${PREFIX}/usr/share/shorewall/version
|
||||
|
||||
if [ -z "$PREFIX" ]; then
|
||||
rm -f /usr/share/shorewall/init
|
||||
ln -s ${DEST}/shorewall /usr/share/shorewall/init
|
||||
ln -s ${DEST}/${INIT} /usr/share/shorewall/init
|
||||
fi
|
||||
|
||||
#
|
||||
@ -549,7 +563,7 @@ if [ -z "$PREFIX" -a -n "$first_install" ]; then
|
||||
else
|
||||
cant_autostart
|
||||
fi
|
||||
else
|
||||
elif [ "$INIT" != rc.firewall ]; then #Slackware starts this automatically
|
||||
cant_autostart
|
||||
fi
|
||||
|
||||
|
||||
@ -115,11 +115,21 @@
|
||||
# established connection will be accepted
|
||||
# from this interface, even if
|
||||
# NEWNOTSYN=No has been specified in
|
||||
# /etc/shorewall/shorewall.conf.
|
||||
# /etc/shorewall/shorewall.conf. In other
|
||||
# words, packets coming in on this interface
|
||||
# are processed as if NEWNOTSYN=Yes had been
|
||||
# specified in /etc/shorewall/shorewall.conf.
|
||||
#
|
||||
# This option has no effect if
|
||||
# NEWNOTSYN=Yes.
|
||||
#
|
||||
# It is the opinion of the author that
|
||||
# NEWNOTSYN=No creates more problems than
|
||||
# it solves and I recommend against using
|
||||
# that setting in shorewall.conf (hence
|
||||
# making the use of the 'newnotsyn'
|
||||
# interface option unnecessary).
|
||||
#
|
||||
# routeback - If specified, indicates that Shorewall
|
||||
# should include rules that allow filtering
|
||||
# traffic arriving on this interface back
|
||||
|
||||
38
STABLE2/masq
38
STABLE2/masq
@ -55,6 +55,27 @@
|
||||
#
|
||||
# This column may not contain DNS Names.
|
||||
#
|
||||
# If you want to leave this column empty
|
||||
# but you need to specify the next column then
|
||||
# place a hyphen ("-") here.
|
||||
#
|
||||
# PROTO -- (Optional) If you wish to restrict this entry to a
|
||||
# particular protocol then enter the protocol
|
||||
# name (from /etc/protocols) or number here.
|
||||
#
|
||||
# PORT(S) -- (Optional) If the PROTO column specifies TCP (protocol 6)
|
||||
# or UDP (protocol 17) then you may list one
|
||||
# or more port numbers (or names from
|
||||
# /etc/services) separated by commas or you
|
||||
# may list a single port range
|
||||
# (<low port>:<high port>).
|
||||
#
|
||||
# Where a comma-separated list is given, your
|
||||
# kernel and iptables must have multiport match
|
||||
# support and a maximum of 15 ports may be
|
||||
# listed.
|
||||
#
|
||||
#
|
||||
# Example 1:
|
||||
#
|
||||
# You have a simple masquerading setup where eth0 connects to
|
||||
@ -94,6 +115,19 @@
|
||||
#
|
||||
# eth0:0 192.168.1.0/24 206.124.146.176
|
||||
#
|
||||
##############################################################################
|
||||
#INTERFACE SUBNET ADDRESS
|
||||
# Example 5:
|
||||
#
|
||||
# You want all outgoing SMTP traffic entering the firewall
|
||||
# on eth1 to be sent from eth0 with source IP address
|
||||
# 206.124.146.177. You want all other outgoing traffic
|
||||
# from eth1 to be sent from eth0 with source IP address
|
||||
# 206.124.146.176.
|
||||
#
|
||||
# eth0 eth1 206.124.146.177 tcp smtp
|
||||
# eth0 eth1 206.124.146.176
|
||||
#
|
||||
# THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!
|
||||
#
|
||||
###############################################################################
|
||||
#INTERFACE SUBNET ADDRESS PROTO PORT(S)
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||||
|
||||
@ -29,8 +29,7 @@
|
||||
# If No or no (or left empty) then NAT will be effective
|
||||
# only through the interface named in the INTERFACE
|
||||
# column
|
||||
# LOCAL If Yes or yes and the ALL INTERFACES column contains
|
||||
# Yes or yes, NAT will be effective from the firewall
|
||||
# LOCAL If Yes or yes, NAT will be effective from the firewall
|
||||
# system
|
||||
##############################################################################
|
||||
#EXTERNAL INTERFACE INTERNAL ALL LOCAL
|
||||
|
||||
@ -1,114 +1,227 @@
|
||||
Shorewall 2.0.1
|
||||
Shorewall 2.0.2
|
||||
|
||||
----------------------------------------------------------------------
|
||||
Problems Corrected since 2.0.0
|
||||
Problems Corrected since 2.0.1
|
||||
|
||||
1) Using actions in the manner recommended in the documentation
|
||||
results in a Warning that the rule is a policy.
|
||||
1) The /etc/init.d/shorewall script installed on Debian by install.sh
|
||||
failed silently due to a missing file
|
||||
(/usr/share/shorewall/wait4ifup). That file is not part of the
|
||||
normal Shorewall distribution and is provided by the Debian
|
||||
maintainer.
|
||||
|
||||
2) When a zone on a single interface is defined using
|
||||
/etc/shorewall/hosts, superfluous rules are generated in the
|
||||
<zone>_frwd chain.
|
||||
2) A meaningless warning message out of the proxyarp file processing
|
||||
has been eliminated.
|
||||
|
||||
3) Thanks to Sean Mathews, a long-standing problem with Proxy ARP and
|
||||
IPSEC has been corrected. Thanks Sean!!!
|
||||
|
||||
4) The "shorewall show log" and "shorewall logwatch" commands
|
||||
incorrectly displayed type 3 ICMP packets.
|
||||
|
||||
5) On Debian systems, an install using the tarball results in an
|
||||
inability to start Shorewall at system boot.
|
||||
|
||||
6) Confusing warning messages regarding IPV6 occur during startup.
|
||||
|
||||
7) Modules listed in /etc/shorewall/modules don't load on Mandrake
|
||||
10.0 final.
|
||||
|
||||
8) "shorewall delete" now correctly deletes dynamic rules from
|
||||
the ruleset. Thanks to Stefan Engel for this fix.
|
||||
|
||||
9) The install.sh script now works correctly on SuSE. Thanks to Alex
|
||||
Wilms for this correction.
|
||||
3) The "shorewall delete" command now correctly removes all dynamic
|
||||
rules pertaining to the host(s) being deleted. Thanks to Stefan
|
||||
Engel for this correction.
|
||||
|
||||
-----------------------------------------------------------------------
|
||||
Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:
|
||||
|
||||
1) The function of 'norfc1918' is now split between that option and a
|
||||
new 'nobogons' option.
|
||||
1) Extension Scripts
|
||||
|
||||
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'.
|
||||
In order for extension scripts to work properly with the new
|
||||
iptables-save/restore integration (see New Feature 1 below), some
|
||||
change may be required to your extension scripts.
|
||||
|
||||
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.
|
||||
If your extension scripts are executing commands other than iptables
|
||||
then those commands must also be written to the restore file (a
|
||||
temporary file in /var/lib/shorewall that is renamed
|
||||
/var/lib/shorewall/restore-base at the end of the operation).
|
||||
|
||||
The following functions should be of help:
|
||||
|
||||
A. save_command() -- saves the passed command to the restore file.
|
||||
|
||||
Example:
|
||||
|
||||
save_command echo Operation Complete
|
||||
|
||||
That command would simply write "echo Operation Complete" to the
|
||||
restore file.
|
||||
|
||||
B. run_and_save_command() -- saves the passed command to the restore
|
||||
file then executes it. The return value is the exit status of the
|
||||
command.
|
||||
|
||||
Example:
|
||||
|
||||
run_and_save_command "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"
|
||||
|
||||
Note that as in this example, when the command involves file
|
||||
redirection then the entire command must be enclosed in quotes. This
|
||||
applies to all of the functions described here.
|
||||
|
||||
C. ensure_and_save_command() -- runs the passed command. If the
|
||||
command fails, the firewall is restored to it's prior saved state
|
||||
and the operation is terminated. If the command succeeds, the
|
||||
command is written to the restore file.
|
||||
|
||||
2) Dynamic Zone support.
|
||||
|
||||
If you don't need to use the "shorewall add" and "shorewall delete"
|
||||
commands, you should set DYNAMIC_ZONES=No in
|
||||
/etc/shorewall/shorewall.conf.
|
||||
|
||||
New Features:
|
||||
|
||||
1) Support for Bridging Firewalls has been added. For details, see
|
||||
1) Shorewall has now been integrated with
|
||||
iptables-save/iptables-restore to provide very fast start and
|
||||
restart. The elements of this integration are as follows:
|
||||
|
||||
http://shorewall.net/bridge.html
|
||||
a) The 'shorewall save' command now saves the current configuration
|
||||
in addition to the current dynamic blacklist. If you have
|
||||
dynamic zones, you will want to issue 'shorewall save' when the
|
||||
zones are empty or the current contents of the zones will be
|
||||
restored by the 'shorewall restore' and 'shorewall -f start'
|
||||
commands.
|
||||
|
||||
2) Support for NETMAP has been added. NETMAP allows NAT to be defined
|
||||
between two network:
|
||||
b) The 'shorewall restore' command has been added. This command
|
||||
restores the configuration at the time of the last 'save'.
|
||||
|
||||
a.b.c.1 -> x.y.z.1
|
||||
a.b.c.2 -> x.y.z.2
|
||||
a.b.c.3 -> x.y.z.3
|
||||
...
|
||||
c) The -f (fast) option has been added to 'shorewall start'. When
|
||||
specified (e.g. 'shorewall -f start'), shorewall will perform a
|
||||
'shorewall restore' if there is a saved configuration. If there
|
||||
is no saved configuration, a normal 'shorewall start' is
|
||||
performed.
|
||||
|
||||
http://shorewall.net/netmap.html
|
||||
d) The /etc/init.d/shorewall script now translates the 'start'
|
||||
command into 'shorewall -f start' so that fast restart is
|
||||
possible.
|
||||
|
||||
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".
|
||||
e) When a state-changing command encounters an error and there is a
|
||||
current saved configuration, that configuration will be restored
|
||||
(currently, the firewall is placed in the 'stopped' state).
|
||||
|
||||
Commands affected by this are:
|
||||
f) If you have previously saved the running configuration and want
|
||||
Shorewall to discard it, use the 'shorewall forget' command.
|
||||
|
||||
shorewall -x show [ <chain>[ <chain> ...] ]
|
||||
shorewall -x show tos|mangle
|
||||
shorewall -x show nat
|
||||
shorewall -x status
|
||||
shorewall -x monitor [ <interval> ]
|
||||
WARNING: iptables 1.2.9 is broken with respect to iptables-save;
|
||||
If your kernel has connection tracking match support, you must
|
||||
patch iptables 1.2.9 with the iptables patch availale from
|
||||
the Shorewall errata page.
|
||||
|
||||
4) Shorewall now traps two common zone definition errors:
|
||||
2) The previous implementation of dynamic zones was difficult to
|
||||
maintain. I have changed the code to make dynamic zones optional
|
||||
under the control of the DYNAMIC_ZONES option in
|
||||
/etc/shorewall/shorewall.conf.
|
||||
|
||||
- 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.
|
||||
3) In earlier Shorewall 2.0 releases, Shorewall searches in order the
|
||||
following directories for configuration files.
|
||||
|
||||
In the second case, the following will appear during "shorewall
|
||||
[re]start" or "shorewall check":
|
||||
a) The directory specified in a 'try' command or specified using
|
||||
the -c option.
|
||||
|
||||
Determining Hosts in Zones...
|
||||
...
|
||||
Error: Invalid zone definition for zone <name of zone>
|
||||
Terminated
|
||||
b) /etc/shorewall
|
||||
|
||||
5) To support bridging, the following options have been added to
|
||||
entries in /etc/shorewall/hosts:
|
||||
c) /usr/share/shorewall
|
||||
|
||||
norfc1918
|
||||
nobogons
|
||||
blacklist
|
||||
tcpflags
|
||||
nosmurfs
|
||||
newnotsyn
|
||||
In this release, the CONFIG_PATH option is added to shorewall.conf.
|
||||
CONFIG_PATH contains a list of directory names separated by colons
|
||||
(":"). If not set or set to a null value (e.g., CONFIG_PATH="") then
|
||||
"CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed.
|
||||
|
||||
With the exception of 'newnotsyn', these options are only
|
||||
useful when the entry refers to a bridge port.
|
||||
Now Shorewall searches for shorewall.conf according to the old
|
||||
rules and for other configuration files as follows:
|
||||
|
||||
a) The directory specified in a 'try' command or specified using
|
||||
the -c option.
|
||||
|
||||
b) Each directory in $CONFIG_PATH is searched in sequence.
|
||||
|
||||
In case it is not obvious, your CONFIG_PATH should include
|
||||
/usr/share/shorewall and your shorewall.conf file must be in the
|
||||
directory specified via -c or in a try command, in /etc/shorewall
|
||||
or in /usr/share/shorewall.
|
||||
|
||||
For distribution packagers, the default CONFIG_PATH is set in
|
||||
/usr/share/shorewall/configpath. You can customize this file to
|
||||
have a default that differs from mine.
|
||||
|
||||
4) Previously, in /etc/shorewall/nat a Yes (or yes) in the LOCAL column
|
||||
would only take effect if the ALL INTERFACES column also contained
|
||||
Yes or yes. Now, the LOCAL columns contents are treated
|
||||
independently of the contents of the ALL INTERFACES column.
|
||||
|
||||
5) The folks at Mandrake have created yet another kernel module
|
||||
naming convention (module names end in "ko.gz"). As a consequence,
|
||||
beginning with this release, if MODULE_SUFFIX isn't specified in
|
||||
shorewall.conf, then the default value is "o gz ko o.gz ko.gz".
|
||||
|
||||
6) An updated bogons file is included in this release.
|
||||
|
||||
7) In /etc/shorewall/rules and in action files generated from
|
||||
/usr/share/shorewall/action.template, rules that perform logging can
|
||||
specify an optional "log tag". A log tag is a string of alphanumeric
|
||||
characters and is specified by following the log level with ":" and
|
||||
the log tag.
|
||||
|
||||
Example:
|
||||
|
||||
#ZONE HOST(S) OPTIONS
|
||||
net br0:eth0 norfc1918,nobogons,blacklist,tcpflags,nosmurfs
|
||||
|
||||
ACCEPT:info:ftp net dmz tcp 21
|
||||
|
||||
The log tag is appended to the log prefix generated by the LOGPREFIX
|
||||
variable in /etc/shorewall/conf. If "ACCEPT:info" generates the log
|
||||
prefix "Shorewall:net2dmz:ACCEPT:" then "ACCEPT:info:ftp" will
|
||||
generate "Shorewall:net2dmz:ACCEPT:ftp " (note the trailing blank).
|
||||
The maximum length of a log prefix supported by iptables is 29
|
||||
characters; if a larger prefix is generated, Shorewall will issue a
|
||||
warning message and will truncate the prefix to 29 characters.
|
||||
|
||||
8) A new "-q" option has been added to /sbin/shorewall commands. It
|
||||
causes the start, restart, check and refresh commands to produce
|
||||
much less output so that warning messages are more visible (when
|
||||
testing this change, I discovered a bug where a bogus warning
|
||||
message was being generated).
|
||||
|
||||
9) Shorewall now uses 'modprobe' to load kernel modules if that utility
|
||||
is available in the PATH; otherwise, 'insmod' is used.
|
||||
|
||||
10) It is now possible to restrict entries in the /etc/shorewall/masq
|
||||
file to particular protocols and destination port(s). Two new
|
||||
columns (PROTO and PORT(S)) have been added to the file.
|
||||
|
||||
Example:
|
||||
|
||||
You want all outgoing SMTP traffic entering the firewall
|
||||
on eth1 to be sent from eth0 with source IP address
|
||||
206.124.146.177. You want all other outgoing traffic
|
||||
from eth1 to be sent from eth0 with source IP address
|
||||
206.124.146.176.
|
||||
|
||||
eth0 eth1 206.124.146.177 tcp 25
|
||||
eth0 eth1 206.124.146.176
|
||||
|
||||
THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!
|
||||
|
||||
Assuming that 10.0.0.0/8 is the only host/network connected
|
||||
to eth1, the progress message at "shorewall start" would be:
|
||||
|
||||
Masqueraded Networks and Hosts:
|
||||
To 0.0.0.0/0 (tcp 25) from 10.0.0.0/8 through eth0 using 206.124.146.177
|
||||
To 0.0.0.0/0 (all) from 10.0.0.0/8 through eth0 using 206.124.146.176
|
||||
|
||||
11) Two new actions are available in the /etc/shorewall/rules file.
|
||||
|
||||
ACCEPT+ -- Behaves like ACCEPT with the exception that it exempts
|
||||
matching connections from subsequent DNAT[-] and
|
||||
REDIRECT[-] rules.
|
||||
|
||||
NONAT -- Exempts matching connections from subsequent DNAT[-]
|
||||
and REDIRECT[-] rules.
|
||||
|
||||
12) A new extension script 'initdone' has been added. This script is invoked
|
||||
at the same point as the 'common' script was previously and is useful for
|
||||
users who mis-used that script under Shorewall 1.x (the script was intended
|
||||
for adding rules to the 'common' chain but many users treated it as a script
|
||||
for adding rules before Shorewall's).
|
||||
|
||||
13) Installing/Upgrading Shorewall on Slackware has been
|
||||
improved. Slackware users must use the tarball and must modify
|
||||
settings in the install.sh script before running it as follows:
|
||||
|
||||
DEST="/etc/rc.d"
|
||||
INIT="rc.firewall"
|
||||
|
||||
Thanks to Alex Wilms for helping with this change.
|
||||
|
||||
@ -25,6 +25,13 @@
|
||||
# LOG, QUEUE or an <action>.
|
||||
#
|
||||
# ACCEPT -- allow the connection request
|
||||
# ACCEPT+ -- like ACCEPT but also excludes the
|
||||
# connection from any subsequent
|
||||
# DNAT[-] or REDIRECT[-] rules
|
||||
# NONAT -- Excludes the connection from any
|
||||
# subsequent DNAT[-] or REDIRECT[-]
|
||||
# rules but doesn't generate a rule
|
||||
# to accept the traffic.
|
||||
# DROP -- ignore the request
|
||||
# REJECT -- disallow the request and return an
|
||||
# icmp-unreachable or an RST packet.
|
||||
@ -70,6 +77,15 @@
|
||||
# to a separate log through use of ulogd
|
||||
# (http://www.gnumonks.org/projects/ulogd).
|
||||
#
|
||||
# Actions specifying logging may be followed by a
|
||||
# log tag (a string of alphanumeric characters)
|
||||
# are appended to the string generated by the
|
||||
# LOGPREFIX (in /etc/shorewall/shorewall.conf).
|
||||
#
|
||||
# Example: ACCEPT:info:ftp would include 'ftp '
|
||||
# at the end of the log prefix generated by the
|
||||
# LOGPREFIX setting.
|
||||
#
|
||||
# SOURCE Source hosts to which the rule applies. May be a zone
|
||||
# defined in /etc/shorewall/zones, $FW to indicate the
|
||||
# firewall itself, or "all" If the ACTION is DNAT or
|
||||
|
||||
@ -80,6 +80,10 @@
|
||||
# "dropped" addresses so that it will
|
||||
# be automatically reinstated the
|
||||
# next time that Shorewall starts.
|
||||
# Save the current state so that 'shorewall
|
||||
# restore' can be used.
|
||||
#
|
||||
# shorewall forget Discard the data saved by 'shorewall save'
|
||||
#
|
||||
# shorewall ipaddr [ <address>/<cidr> | <address> <netmask> ]
|
||||
#
|
||||
@ -160,6 +164,7 @@ get_config() {
|
||||
exit 2
|
||||
fi
|
||||
fi
|
||||
|
||||
}
|
||||
|
||||
#
|
||||
@ -530,7 +535,7 @@ help()
|
||||
#
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
echo "Usage: $(basename $0) [debug|trace] [nolock] [-c <directory>] [ -x ] <command>"
|
||||
echo "Usage: $(basename $0) [debug|trace] [nolock] [-c <directory>] [ -x ] [ -q ] <command>"
|
||||
echo "where <command> is one of:"
|
||||
echo " add <interface>[:<host>] <zone>"
|
||||
echo " allow <address> ..."
|
||||
@ -538,6 +543,7 @@ usage() # $1 = exit status
|
||||
echo " clear"
|
||||
echo " delete <interface>[:<host>] <zone>"
|
||||
echo " drop <address> ..."
|
||||
echo " forget"
|
||||
echo " help [ <command > | host | address ]"
|
||||
echo " hits"
|
||||
echo " ipcalc [ <address>/<vlsm> | <address> <netmask> ]"
|
||||
@ -548,6 +554,7 @@ usage() # $1 = exit status
|
||||
echo " reject <address> ..."
|
||||
echo " reset"
|
||||
echo " restart"
|
||||
echo " restore"
|
||||
echo " save"
|
||||
echo " show [<chain> [ <chain> ... ]|classifiers|connections|log|nat|tc|tos]"
|
||||
echo " start"
|
||||
@ -585,34 +592,60 @@ if [ $# -gt 0 ] && [ "$1" = "nolock" ]; then
|
||||
fi
|
||||
|
||||
SHOREWALL_DIR=
|
||||
QUIET=
|
||||
IPT_OPTIONS="-nv"
|
||||
FAST=
|
||||
|
||||
done=0
|
||||
|
||||
while [ $done -eq 0 ]; do
|
||||
[ $# -eq 0 ] && usage 1
|
||||
case $1 in
|
||||
-c)
|
||||
[ $# -eq 1 ] && usage 1
|
||||
option=$1
|
||||
case $option in
|
||||
-*)
|
||||
option=${option#-}
|
||||
|
||||
if [ ! -d $2 ]; then
|
||||
if [ -e $2 ]; then
|
||||
echo "$2 is not a directory" >&2 && exit 2
|
||||
else
|
||||
echo "Directory $2 does not exist" >&2 && exit 2
|
||||
fi
|
||||
fi
|
||||
[ -z "$option" ] && usage 1
|
||||
|
||||
while [ -n "$option" ]; do
|
||||
case $option in
|
||||
c)
|
||||
[ $# -eq 1 ] && usage 1
|
||||
|
||||
SHOREWALL_DIR=$2
|
||||
shift
|
||||
shift
|
||||
;;
|
||||
-x)
|
||||
IPT_OPTIONS="-xnv"
|
||||
shift
|
||||
;;
|
||||
*)
|
||||
done=1
|
||||
;;
|
||||
if [ ! -d $2 ]; then
|
||||
if [ -e $2 ]; then
|
||||
echo "$2 is not a directory" >&2 && exit 2
|
||||
else
|
||||
echo "Directory $2 does not exist" >&2 && exit 2
|
||||
fi
|
||||
fi
|
||||
|
||||
SHOREWALL_DIR=$2
|
||||
option=
|
||||
shift
|
||||
;;
|
||||
x*)
|
||||
IPT_OPTIONS="-xnv"
|
||||
option=${option#x}
|
||||
;;
|
||||
q*)
|
||||
QUIET=Yes
|
||||
option=${option#q}
|
||||
;;
|
||||
f*)
|
||||
FAST=Yes
|
||||
option=${option#f}
|
||||
;;
|
||||
*)
|
||||
usage 1
|
||||
;;
|
||||
esac
|
||||
done
|
||||
shift
|
||||
;;
|
||||
*)
|
||||
done=1
|
||||
;;
|
||||
esac
|
||||
done
|
||||
|
||||
@ -621,6 +654,7 @@ if [ $# -eq 0 ]; then
|
||||
fi
|
||||
|
||||
[ -n "$SHOREWALL_DIR" ] && export SHOREWALL_DIR
|
||||
[ -n "$QUIET" ] && export QUIET
|
||||
|
||||
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
|
||||
MUTEX_TIMEOUT=
|
||||
@ -638,6 +672,8 @@ else
|
||||
exit 2
|
||||
fi
|
||||
|
||||
ensure_config_path
|
||||
|
||||
config=$(find_file shorewall.conf)
|
||||
|
||||
if [ -f $config ]; then
|
||||
@ -647,6 +683,10 @@ else
|
||||
exit 2
|
||||
fi
|
||||
|
||||
ensure_config_path
|
||||
|
||||
export CONFIG_PATH
|
||||
|
||||
[ -z "${STATEDIR}" ] && STATEDIR=/var/state/shorewall
|
||||
|
||||
if [ ! -f $FIREWALL ]; then
|
||||
@ -691,7 +731,23 @@ case $(echo -n "Testing") in
|
||||
esac
|
||||
|
||||
case "$1" in
|
||||
start|stop|restart|reset|clear|refresh|check)
|
||||
start)
|
||||
[ $# -ne 1 ] && usage 1
|
||||
get_config
|
||||
if [ -n "$FAST" ]; then
|
||||
if [ -f /var/lib/shorewall/restore ]; then
|
||||
echo Restoring Shorewall...
|
||||
. /var/lib/shorewall/restore
|
||||
date > $STATEDIR/restarted
|
||||
echo Shorewall restored
|
||||
else
|
||||
exec $SHOREWALL_SHELL $FIREWALL $debugging $nolock start
|
||||
fi
|
||||
else
|
||||
exec $SHOREWALL_SHELL $FIREWALL $debugging $nolock start
|
||||
fi
|
||||
;;
|
||||
stop|restart|reset|clear|refresh|check)
|
||||
[ $# -ne 1 ] && usage 1
|
||||
get_config
|
||||
exec $SHOREWALL_SHELL $FIREWALL $debugging $nolock $1
|
||||
@ -909,11 +965,24 @@ case "$1" in
|
||||
[ -n "$debugging" ] && set -x
|
||||
[ $# -ne 1 ] && usage 1
|
||||
mutex_on
|
||||
|
||||
if qt iptables -L shorewall -n; then
|
||||
[ -d /var/lib/shorewall ] || mkdir /var/lib/shorewall
|
||||
|
||||
if iptables -L dynamic -n > /var/lib/shorewall/save; then
|
||||
echo "Dynamic Rules Saved"
|
||||
echo " Dynamic Rules Saved"
|
||||
if [ -f /var/lib/shorewall/restore-base ]; then
|
||||
cp -f /var/lib/shorewall/restore-base /var/lib/shorewall/restore-$$
|
||||
if iptables-save >> /var/lib/shorewall/restore-$$ ; then
|
||||
echo EOF >> /var/lib/shorewall/restore-$$
|
||||
mv -f /var/lib/shorewall/restore-$$ /var/lib/shorewall/restore
|
||||
chmod +x /var/lib/shorewall/restore
|
||||
echo " Currently-running Configuration Saved"
|
||||
else
|
||||
rm -f /var/lib/shorewall/restore-$$
|
||||
echo " ERROR: Currently-running Configuration Not Saved"
|
||||
fi
|
||||
fi
|
||||
else
|
||||
echo "Error Saving the Dynamic Rules"
|
||||
fi
|
||||
@ -922,6 +991,11 @@ case "$1" in
|
||||
fi
|
||||
mutex_off
|
||||
;;
|
||||
forget)
|
||||
rm -f /var/lib/shorewall/restore
|
||||
rm -f /var/lib/shorewall/save
|
||||
echo " Previously saved information discarded"
|
||||
;;
|
||||
ipcalc)
|
||||
[ -n "$debugging" ] && set -x
|
||||
if [ $# -eq 2 ]; then
|
||||
@ -957,6 +1031,16 @@ case "$1" in
|
||||
;;
|
||||
esac
|
||||
;;
|
||||
restore)
|
||||
if [ -f /var/lib/shorewall/restore ]; then
|
||||
echo Restoring Shorewall...
|
||||
. /var/lib/shorewall/restore
|
||||
echo Shorewall restored
|
||||
else
|
||||
echo "File /var/lib/shorewall/restore: file not found"
|
||||
exit 2
|
||||
fi
|
||||
;;
|
||||
call)
|
||||
[ -n "$debugging" ] && set -x
|
||||
#
|
||||
|
||||
@ -90,12 +90,21 @@ LOGFORMAT="Shorewall:%s:%s:"
|
||||
# maximum initial burst size that will be logged. If set empty, the default
|
||||
# value of 5 will be used.
|
||||
#
|
||||
# If BOTH variables are set empty then logging will not be rate-limited.
|
||||
#
|
||||
# Example:
|
||||
#
|
||||
# LOGRATE=10/minute
|
||||
# LOGBURST=5
|
||||
#
|
||||
# If BOTH variables are set empty then logging will not be rate-limited.
|
||||
# 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.
|
||||
#
|
||||
|
||||
LOGRATE=
|
||||
@ -236,6 +245,19 @@ STATEDIR=/var/lib/shorewall
|
||||
|
||||
MODULESDIR=
|
||||
|
||||
#
|
||||
# CONFIGURATION SEARCH PATH
|
||||
#
|
||||
# This option holds a list of directory names separated by colons
|
||||
# (":"). Shorewall will search each directory in turn when looking for a
|
||||
# configuration file. When processing a 'try' command or a command
|
||||
# containing the "-c" option, Shorewall will automatically add the
|
||||
# directory specified in the command to the front of this list.
|
||||
#
|
||||
# If not specified or specified as null ("CONFIG_PATH=""),
|
||||
# CONFIG_PATH=/etc/shorewall:/usr/share/shorewall is assumed.
|
||||
|
||||
CONFIG_PATH=/etc/shorewall:/usr/share/shorewall
|
||||
################################################################################
|
||||
# F I R E W A L L O P T I O N S
|
||||
################################################################################
|
||||
@ -515,9 +537,9 @@ BLACKLISTNEWONLY=Yes
|
||||
#
|
||||
# When loading a module named in /etc/shorewall/modules, Shorewall normally
|
||||
# looks in the MODULES DIRECTORY (see MODULESDIR above) for files whose names
|
||||
# end in ".o", ".ko", ".gz" or "o.gz". If your distribution uses a different
|
||||
# naming convention then you can specify the suffix (extension) for module
|
||||
# names in this variable.
|
||||
# end in ".o", ".ko", ".gz", "o.gz" or "ko.gz" . If your distribution uses a
|
||||
# different naming convention then you can specify the suffix (extension) for
|
||||
# module names in this variable.
|
||||
#
|
||||
# To see what suffix is used by your distribution:
|
||||
#
|
||||
@ -556,6 +578,14 @@ DISABLE_IPV6=Yes
|
||||
#
|
||||
|
||||
BRIDGING=No
|
||||
|
||||
#
|
||||
# DYNAMIC ZONES
|
||||
#
|
||||
# If you need to be able to add and delete hosts from zones dynamically then
|
||||
# set DYNAMIC_ZONES=Yes. Otherwise, set DYNAMIC_ZONES=No.
|
||||
|
||||
DYNAMIC_ZONES=No
|
||||
################################################################################
|
||||
# P A C K E T D I S P O S I T I O N
|
||||
################################################################################
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
%define name shorewall
|
||||
%define version 2.0.1
|
||||
%define version 2.0.2
|
||||
%define release 1
|
||||
%define prefix /usr
|
||||
|
||||
@ -91,6 +91,7 @@ fi
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/hosts
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/blacklist
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/init
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/initdone
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/start
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/stop
|
||||
%attr(0600,root,root) %config(noreplace) /etc/shorewall/stopped
|
||||
@ -135,10 +136,21 @@ fi
|
||||
%attr(0544,root,root) /usr/share/shorewall/help
|
||||
%attr(0600,root,root) /usr/share/shorewall/rfc1918
|
||||
%attr(0600,root,root) /usr/share/shorewall/bogons
|
||||
%attr(0600,root,root) /usr/share/shorewall/configpath
|
||||
|
||||
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
|
||||
|
||||
%changelog
|
||||
* Thu May 13 2004 Tom Eastep tom@shorewall.net
|
||||
- Updated for 2.0.2-1
|
||||
* Mon May 10 2004 Tom Eastep tom@shorewall.net
|
||||
- Add /etc/shorewall/initdone
|
||||
* Fri May 07 2004 Tom Eastep tom@shorewall.net
|
||||
- Shorewall 2.0.2-RC1
|
||||
* Tue May 04 2004 Tom Eastep tom@shorewall.net
|
||||
- Shorewall 2.0.2-Beta2
|
||||
* Tue Apr 13 2004 Tom Eastep tom@shorewall.net
|
||||
- Add /usr/share/shorewall/configpath
|
||||
* Mon Apr 05 2004 Tom Eastep tom@shorewall.net
|
||||
- Updated for 2.0.1-1
|
||||
* Thu Apr 02 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.1
|
||||
VERSION=2.0.2
|
||||
|
||||
usage() # $1 = exit status
|
||||
{
|
||||
|
||||
@ -18,10 +18,130 @@ 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-04-05<br>
|
||||
<p>2004-05-13<br>
|
||||
</p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<p><b>3/14/2004 - Shorewall 2.0.0b </b><b></b></p>
|
||||
<p><b> 4/5/2004 - Shorewall 2.0.1</b><b></b><br>
|
||||
</p>
|
||||
Problems Corrected since 2.0.0<br>
|
||||
<br>
|
||||
<ol>
|
||||
<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>
|
||||
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>
|
||||
<br>
|
||||
<ol>
|
||||
<li>Support for Bridging Firewalls has been added. For details,
|
||||
see<br>
|
||||
<br>
|
||||
<a href="http://shorewall.net/bridge.html">http://shorewall.net/bridge.html</a><br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Support for NETMAP has been added. NETMAP allows NAT to be
|
||||
defined between two network:<br>
|
||||
<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>
|
||||
<a href="http://shorewall.net/netmap.htm">http://shorewall.net/netmap.htm</a><br>
|
||||
<br>
|
||||
</li>
|
||||
<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>
|
||||
Commands affected by this are:<br>
|
||||
<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</li>
|
||||
</ol>
|
||||
<p><b>3/14/2004 - Shorewall 2.0.0b </b></p>
|
||||
Corrects two problems:<br>
|
||||
<ol>
|
||||
<li>Thanks to Sean Mathews, the long-standing problem with
|
||||
|
||||
@ -21,10 +21,6 @@
|
||||
<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
|
||||
@ -43,14 +39,16 @@ Repository</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;">
|
||||
<div style="text-align: left;"><a href="http://www.shorewall.net"
|
||||
target="_top"><br>
|
||||
</a></div>
|
||||
target="_top"><img alt="(Protected by Shorewall)"
|
||||
src="images/ProtectedBy.png"
|
||||
style="border: 0px solid ; width: 216px; height: 45px;" title=""></a></div>
|
||||
<a href="http://www.shorewall.net" target="_top"></a></div>
|
||||
<p><br>
|
||||
<a href="copyright.htm"> </a> </p>
|
||||
</body>
|
||||
|
||||
@ -47,7 +47,7 @@ compatibility mode).</li>
|
||||
<h3>What is Shorewall?</h3>
|
||||
<div style="margin-left: 40px;">The Shoreline Firewall, more
|
||||
commonly known as "Shorewall", is
|
||||
high-level tool for configuring Netfilter. You describe your
|
||||
a 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
|
||||
the iptables utility, Shorewall configures Netfilter to match your
|
||||
@ -118,129 +118,251 @@ Documentation License"</a>. </div>
|
||||
<p>Copyright © 2001-2004 Thomas M. Eastep </p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<h2>News</h2>
|
||||
<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><br>
|
||||
<b></b></p>
|
||||
Problems Corrected since 2.0.0<br>
|
||||
<br>
|
||||
<p><b>5/13/2004 - Shorewall 2.0.2</b><b> </b><b> <img
|
||||
alt="(New)" src="images/new10.gif"
|
||||
style="border: 0px solid ; width: 28px; height: 12px;" title=""></b></p>
|
||||
<p>Problems Corrected since 2.0.1<br>
|
||||
</p>
|
||||
<ol>
|
||||
<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>
|
||||
<li>The /etc/init.d/shorewall script installed on Debian by
|
||||
install.sh failed silently due to a missing file
|
||||
(/usr/share/shorewall/wait4ifup). That file is not part of the normal
|
||||
Shorewall distribution and is provided by the Debian maintainer.</li>
|
||||
<li>A meaningless warning message out of the proxyarp file
|
||||
processing has been eliminated.</li>
|
||||
<li>The "shorewall delete" command now correctly removes all
|
||||
dynamic rules pertaining to the host(s) being deleted. Thanks to Stefan
|
||||
Engel for this correction.</li>
|
||||
</ol>
|
||||
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>
|
||||
<li>Extension Scripts -- In order for extension scripts to work
|
||||
properly with the new iptables-save/restore integration (see New
|
||||
Feature 1 below), some change may be required to your extension
|
||||
scripts. If your extension scripts are executing commands other than
|
||||
iptables then those commands must also be written to the restore file
|
||||
(a temporary file in /var/lib/shorewall that is renamed
|
||||
/var/lib/shorewall/restore-base at the end of the operation).<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>
|
||||
The following functions should be of help:<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>
|
||||
A. save_command() -- saves the passed command to the restore file.<br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
save_command echo Operation
|
||||
Complete<br>
|
||||
<br>
|
||||
That command would simply write "echo Operation Complete"
|
||||
to the restore file.<br>
|
||||
<br>
|
||||
B. run_and_save_command() -- saves the passed command to the restore
|
||||
file then executes it. The return value is the exit status of the
|
||||
command.<br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
run_and_save_command "echo 1 >
|
||||
/proc/sys/net/ipv4/icmp_echo_ignore_all"<br>
|
||||
<br>
|
||||
Note that as in this example, when the command
|
||||
involves file redirection then the entire command must be enclosed in
|
||||
quotes. This applies to all of the functions described here.<br>
|
||||
<br>
|
||||
C. ensure_and_save_command() -- runs the passed command. If the command
|
||||
fails, the firewall is restored to it's prior saved state and the
|
||||
operation is terminated. If the command succeeds, the command is
|
||||
written to the restore file.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Dynamic Zone support -- If you don't need to use the
|
||||
"shorewall add" and "shorewall delete commands, you should set
|
||||
DYNAMIC_ZONES=No in /etc/shorewall/shorewall.conf.</li>
|
||||
</ol>
|
||||
New Features:<br>
|
||||
<br>
|
||||
<ol>
|
||||
<li>Support for Bridging Firewalls has been added. For details,
|
||||
see<br>
|
||||
<li>Shorewall has now been integrated with
|
||||
iptables-save/iptables-restore to provide very fast start and restart.
|
||||
The elements of this integration are as follows:<br>
|
||||
<br>
|
||||
<a href="http://shorewall.net/bridge.html">http://shorewall.net/bridge.html</a><br>
|
||||
a) The 'shorewall save' command now saves the current configuration in
|
||||
addition to the current dynamic blacklist. If you have dynamic zones,
|
||||
you will want to issue 'shorewall save' when the zones are empty or the
|
||||
current contents of the zones will be restored by the 'shorewall
|
||||
restore' and 'shorewall -f start' commands.<br>
|
||||
<br>
|
||||
b) The 'shorewall restore' command has been added. This command
|
||||
restores the configuration at the time of the last 'save'.<br>
|
||||
<br>
|
||||
c) The -f (fast) option has been added to 'shorewall start'. When
|
||||
specified (e.g. 'shorewall -f start'), shorewall will perform a
|
||||
'shorewall restore' if there is a saved configuration. If there is no
|
||||
saved configuration, a normal 'shorewall start' is performed.<br>
|
||||
<br>
|
||||
d) The /etc/init.d/shorewall script now translates the 'start' command
|
||||
into 'shorewall -f start' so that fast restart is possible.<br>
|
||||
<br>
|
||||
e) When a state-changing command encounters an error and there is
|
||||
current saved configuration, that configuration will be restored
|
||||
(currently, the firewall is placed in the 'stopped' state).<br>
|
||||
<br>
|
||||
f) If you have previously saved the running configuration and want
|
||||
Shorewall to discard it, use the 'shorewall forget' command. WARNING:
|
||||
iptables 1.2.9 is broken with respect to iptables-save; if your kernel
|
||||
has connection tracking match support, you must patch iptables 1.2.9
|
||||
with the iptables patch availale from the Shorewall errata page.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Support for NETMAP has been added. NETMAP allows NAT to be
|
||||
defined between two network:<br>
|
||||
<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>
|
||||
<a href="http://shorewall.net/netmap.htm">http://shorewall.net/netmap.htm</a><br>
|
||||
<li>The previous implementation of dynamic zones was difficult
|
||||
to maintain. I have changed the code to make dynamic zones optional
|
||||
under the control of the DYNAMIC_ZONES option in
|
||||
/etc/shorewall/shorewall.conf.<br>
|
||||
<br>
|
||||
</li>
|
||||
<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>
|
||||
<li>In earlier Shorewall 2.0 releases, Shorewall searches in
|
||||
order the following directories for configuration files.<br>
|
||||
<br>
|
||||
Commands affected by this are:<br>
|
||||
a) The directory specified in a 'try' command or specified using the -c
|
||||
option.<br>
|
||||
b) /etc/shorewall<br>
|
||||
c) /usr/share/shorewall<br>
|
||||
<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>
|
||||
In this release, the CONFIG_PATH option is added to shorewall.conf.
|
||||
CONFIG_PATH contains a list of directory names separated by colons
|
||||
(":"). If not set or set to a null value (e.g., CONFIG_PATH="") then
|
||||
"CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed. Now
|
||||
Shorewall searches for shorewall.conf according to the old rules and
|
||||
for other configuration files as follows:<br>
|
||||
<br>
|
||||
a) The directory specified in a 'try' command or specified using the -c
|
||||
option.<br>
|
||||
b) Each directory in $CONFIG_PATH is searched in sequence.<br>
|
||||
<br>
|
||||
In case it is not obvious, your CONFIG_PATH should include
|
||||
/usr/share/shorewall and your shorewall.conf file must be in the
|
||||
directory specified via -c or in a try command, in /etc/shorewall or in
|
||||
/usr/share/shorewall.<br>
|
||||
<br>
|
||||
For distribution packagers, the default CONFIG_PATH is set in
|
||||
/usr/share/shorewall/configpath. You can customize this file to have a
|
||||
default that differs from mine.<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>
|
||||
<li>Previously, in /etc/shorewall/nat a Yes (or yes) in the
|
||||
LOCAL column would only take effect if the ALL INTERFACES column also
|
||||
contained Yes or yes. Now, the LOCAL columns contents are treated
|
||||
independently of the contents of the ALL INTERFACES column.<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>
|
||||
<li>The folks at Mandrake have created yet another kernel
|
||||
module naming convention (module names end in "ko.gz"). As a
|
||||
consequence, beginning with this release, if MODULE_SUFFIX isn't
|
||||
specified in shorewall.conf, then the default value is "o gz ko o.gz
|
||||
ko.gz".<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>An updated bogons file is included in this release.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>In /etc/shorewall/rules and in action files generated from
|
||||
/usr/share/shorewall/action.template, rules that perform logging can
|
||||
specify an optional "log tag". A log tag is a string of alphanumeric
|
||||
characters and is specified by following the log level with ":" and the
|
||||
log tag.<br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
ACCEPT:info:ftp
|
||||
net dmz
|
||||
tcp 21<br>
|
||||
<br>
|
||||
The log tag is appended to the log prefix generated by the LOGPREFIX
|
||||
variable in /etc/shorewall/conf. If "ACCEPT:info" generates the log
|
||||
prefix "Shorewall:net2dmz:ACCEPT:" then "ACCEPT:info:ftp" will generate
|
||||
"Shorewall:net2dmz:ACCEPT:ftp " (note the trailing blank). The maximum
|
||||
length of a log prefix supported by iptables is 29 characters; if a
|
||||
larger prefix is generated, Shorewall will issue a warning message and
|
||||
will truncate the prefix to 29 characters.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>A new "-q" option has been added to /sbin/shorewall
|
||||
commands. It causes the start, restart, check and refresh commands to
|
||||
produce much less output so that warning messages are more visible
|
||||
(when testing this change, I discovered a bug where a bogus warning
|
||||
message was being generated).<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Shorewall now uses 'modprobe' to load kernel modules if
|
||||
that utility is available in the PATH; otherwise, 'insmod' is used.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>It is now possible to restrict entries in the
|
||||
/etc/shorewall/masq file to particular protocols and destination
|
||||
port(s). Two new columns (PROTO and PORT(S)) have been added to the
|
||||
file.<br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
You want all outgoing SMTP traffic entering the firewall on eth1 to be
|
||||
sent from eth0 with source IP address 206.124.146.177. You want all
|
||||
other outgoing traffic from eth1 to be sent from eth0 with source IP
|
||||
address 206.124.146.176.<br>
|
||||
<br>
|
||||
eth0
|
||||
eth1 206.124.146.177 tcp 25<br>
|
||||
eth0
|
||||
eth1 206.124.146.176<br>
|
||||
<br>
|
||||
THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!<br>
|
||||
<br>
|
||||
Assuming that 10.0.0.0/8 is the only host/network connected to eth1,
|
||||
the progress message at "shorewall start" would be:<br>
|
||||
<br>
|
||||
Masqueraded Networks and Hosts:<br>
|
||||
To 0.0.0.0/0 (tcp 25) from
|
||||
10.0.0.0/8 through eth0 using 206.124.146.177<br>
|
||||
To 0.0.0.0/0 (all) from 10.0.0.0/8
|
||||
through eth0 using 206.124.146.176<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Two new actions are available in the /etc/shorewall/rules
|
||||
file.<br>
|
||||
<br>
|
||||
ACCEPT+ -- Behaves like ACCEPT
|
||||
with the exception that it exempts matching connections from subsequent
|
||||
DNAT[-] and REDIRECT[-] rules.<br>
|
||||
NONAT -- Exempts
|
||||
matching connections from subsequent DNAT[-] and REDIRECT[-] rules.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>A new extension script 'initdone' has been added. This
|
||||
script is invoked at the same point as the 'common' script was
|
||||
previously and is useful for users who mis-used that script under
|
||||
Shorewall 1.x (the script was intended for adding rules to the 'common'
|
||||
chain but many users treated it as a script for adding rules before
|
||||
Shorewall's).<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Installing/Upgrading Shorewall on Slackware has been
|
||||
improved. Slackware users must use the tarball and must modify settings
|
||||
in the install.sh script before running it as follows:<br>
|
||||
<br>
|
||||
DEST="/etc/rc.d"<br>
|
||||
INIT="rc.firewall"<br>
|
||||
<br>
|
||||
Thanks to Alex Wilms for helping with this change.<br>
|
||||
</li>
|
||||
</ol>
|
||||
<p><b>4/17/2004 - Presentation at LinuxFest NW</b><b><br>
|
||||
</b></p>
|
||||
<p>Today I gave a presentation at LinuxFest NW in Bellingham. The
|
||||
presentation was entitled "<a
|
||||
href="http://lists.shorewall.net/Shorewall_and_the_Enterprise.htm"
|
||||
target="_blank">Shorewall
|
||||
and the Enterprise</a>" and described the history of Shorewall and gave
|
||||
an overview of its features.<br>
|
||||
</p>
|
||||
<ol>
|
||||
</ol>
|
||||
<p><a href="News.htm">More News</a></p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
@ -276,7 +398,7 @@ please consider making a donation to the <a href="http://www.alz.org/"
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<p><font size="2">Updated 04/12/2004 - <a href="support.htm">Tom Eastep</a></font><br>
|
||||
<p><font size="2">Updated 05/10/2004 - <a href="support.htm">Tom Eastep</a></font><br>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-05-07</pubdate>
|
||||
<pubdate>2004-05-09</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001</year>
|
||||
@ -35,8 +35,7 @@
|
||||
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
|
||||
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
||||
License</ulink></quote>.</para>
|
||||
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
@ -45,9 +44,9 @@
|
||||
|
||||
<important>
|
||||
<para>Before attempting installation, I strongly urge you to read and
|
||||
print a copy of the <ulink
|
||||
url="shorewall_quickstart_guide.htm">Shorewall QuickStart</ulink> Guide
|
||||
for the configuration that most closely matches your own.</para>
|
||||
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
|
||||
QuickStart</ulink> Guide for the configuration that most closely matches
|
||||
your own.</para>
|
||||
</important>
|
||||
|
||||
<warning>
|
||||
@ -65,15 +64,14 @@
|
||||
<listitem>
|
||||
<para>Install the RPM</para>
|
||||
|
||||
<programlisting><command>rpm -ivh <shorewall rpm></command></programlisting>
|
||||
<programlisting><command>rpm -ivh <shorewall rpm></command></programlisting>
|
||||
|
||||
<note>
|
||||
<para>Some SuSE users have encountered a problem whereby rpm reports
|
||||
a conflict with kernel <= 2.2 even though a 2.4 kernel is
|
||||
installed. If this happens, simply use the --nodeps option to
|
||||
rpm.</para>
|
||||
a conflict with kernel <= 2.2 even though a 2.4 kernel is
|
||||
installed. If this happens, simply use the --nodeps option to rpm.</para>
|
||||
|
||||
<programlisting><filename><command>rpm -ivh --nodeps <shorewall rpm></command></filename></programlisting>
|
||||
<programlisting><filename><command>rpm -ivh --nodeps <shorewall rpm></command></filename></programlisting>
|
||||
</note>
|
||||
|
||||
<note>
|
||||
@ -84,10 +82,9 @@
|
||||
|
||||
<programlisting>error: failed dependencies:iproute is needed by shorewall-1.4.x-1</programlisting>
|
||||
|
||||
<para>This may be worked around by using the --nodeps option of
|
||||
rpm.</para>
|
||||
<para>This may be worked around by using the --nodeps option of rpm.</para>
|
||||
|
||||
<programlisting><command>rpm -ivh --nodeps <shorewall rpm></command></programlisting>
|
||||
<programlisting><command>rpm -ivh --nodeps <shorewall rpm></command></programlisting>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
@ -119,9 +116,9 @@
|
||||
|
||||
<important>
|
||||
<para>Before attempting installation, I strongly urge you to read and
|
||||
print a copy of the <ulink
|
||||
url="shorewall_quickstart_guide.htm">Shorewall QuickStart</ulink> Guide
|
||||
for the configuration that most closely matches your own.</para>
|
||||
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
|
||||
QuickStart</ulink> Guide for the configuration that most closely matches
|
||||
your own.</para>
|
||||
</important>
|
||||
|
||||
<para>To install Shorewall using the tarball and install script:</para>
|
||||
@ -137,15 +134,17 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you are running <ulink
|
||||
url="http://www.slackware.com">Slackware</ulink>, edit the install.sh
|
||||
file and change the line</para>
|
||||
<para>If you are running <ulink url="http://www.slackware.com">Slackware</ulink>,
|
||||
you need Shorewall 2.0.2 RC1 or later. You must also edit the
|
||||
install.sh file and change the lines</para>
|
||||
|
||||
<programlisting>DEST=""</programlisting>
|
||||
<programlisting>DEST="/etc/init.d"
|
||||
INIT="shorewall"</programlisting>
|
||||
|
||||
<para>to</para>
|
||||
|
||||
<programlisting>DEST="/etc/rc.d"</programlisting>
|
||||
<programlisting>DEST="/etc/rc.d"
|
||||
INIT="rc.firewall"</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -160,10 +159,9 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Enable Startup by removing
|
||||
<filename>/etc/shorewall/startup_disabled</filename> (Debian users
|
||||
will edit <filename>/etc/default/shorewall</filename> and set
|
||||
startup=1).</para>
|
||||
<para>Enable Startup by removing <filename>/etc/shorewall/startup_disabled</filename>
|
||||
(Debian users will edit <filename>/etc/default/shorewall</filename>
|
||||
and set startup=1).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -175,8 +173,7 @@
|
||||
<listitem>
|
||||
<para>If the install script was unable to configure Shorewall to be
|
||||
started automatically at boot, see <ulink
|
||||
url="starting_and_stopping_shorewall.htm">these
|
||||
instructions</ulink>.</para>
|
||||
url="starting_and_stopping_shorewall.htm">these instructions</ulink>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
@ -186,16 +183,15 @@
|
||||
|
||||
<important>
|
||||
<para>Before attempting installation, I strongly urge you to read and
|
||||
print a copy of the <ulink
|
||||
url="shorewall_quickstart_guide.htm">Shorewall QuickStart</ulink> Guide
|
||||
for the configuration that most closely matches your own.</para>
|
||||
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
|
||||
QuickStart</ulink> Guide for the configuration that most closely matches
|
||||
your own.</para>
|
||||
</important>
|
||||
|
||||
<para>To install my version of Shorewall on a fresh Bering disk, simply
|
||||
replace the <quote>shorwall.lrp</quote> file on the image with the file
|
||||
that you downloaded. See the <ulink url="two-interface.htm">two-interface
|
||||
QuickStart Guide</ulink> for information about further steps
|
||||
required.</para>
|
||||
QuickStart Guide</ulink> for information about further steps required.</para>
|
||||
</section>
|
||||
|
||||
<section id="Upgrade_RPM">
|
||||
@ -215,23 +211,22 @@
|
||||
please check your /etc/shorewall/interfaces file to be sure that it
|
||||
contains an entry for each interface mentioned in the hosts file. Also,
|
||||
there are certain 1.2 rule forms that are no longer supported under 1.4
|
||||
(you must use the new 1.4 syntax). See <ulink
|
||||
url="errata.htm#Upgrade">the upgrade issues</ulink> for details.</para>
|
||||
(you must use the new 1.4 syntax). See <ulink url="errata.htm#Upgrade">the
|
||||
upgrade issues</ulink> for details.</para>
|
||||
</important>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Upgrade the RPM</para>
|
||||
|
||||
<programlisting><command>rpm -Uvh <shorewall rpm file></command></programlisting>
|
||||
<programlisting><command>rpm -Uvh <shorewall rpm file></command></programlisting>
|
||||
|
||||
<note>
|
||||
<para>Some SuSE users have encountered a problem whereby rpm reports
|
||||
a conflict with kernel <= 2.2 even though a 2.4 kernel is
|
||||
installed. If this happens, simply use the --nodeps option to
|
||||
rpm.</para>
|
||||
a conflict with kernel <= 2.2 even though a 2.4 kernel is
|
||||
installed. If this happens, simply use the --nodeps option to rpm.</para>
|
||||
|
||||
<programlisting><command>rpm -Uvh --nodeps <shorewall rpm></command></programlisting>
|
||||
<programlisting><command>rpm -Uvh --nodeps <shorewall rpm></command></programlisting>
|
||||
</note>
|
||||
|
||||
<note>
|
||||
@ -242,17 +237,15 @@
|
||||
|
||||
<programlisting>error: failed dependencies:iproute is needed by shorewall-1.4.0-1</programlisting>
|
||||
|
||||
<para>This may be worked around by using the --nodeps option of
|
||||
rpm.</para>
|
||||
<para>This may be worked around by using the --nodeps option of rpm.</para>
|
||||
|
||||
<programlisting><command>rpm -Uvh --nodeps <shorewall rpm></command></programlisting>
|
||||
<programlisting><command>rpm -Uvh --nodeps <shorewall rpm></command></programlisting>
|
||||
</note>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>See if there are any incompatibilities between your
|
||||
configuration and the new Shorewall version and correct as
|
||||
necessary.</para>
|
||||
configuration and the new Shorewall version and correct as necessary.</para>
|
||||
|
||||
<programlisting><command>shorewall check</command></programlisting>
|
||||
</listitem>
|
||||
@ -282,8 +275,8 @@
|
||||
please check your /etc/shorewall/interfaces file to be sure that it
|
||||
contains an entry for each interface mentioned in the hosts file. Also,
|
||||
there are certain 1.2 rule forms that are no longer supported under 1.4
|
||||
(you must use the new 1.4 syntax). See <ulink
|
||||
url="errata.htm#Upgrade">the upgrade issues</ulink> for details.</para>
|
||||
(you must use the new 1.4 syntax). See <ulink url="errata.htm#Upgrade">the
|
||||
upgrade issues</ulink> for details.</para>
|
||||
</important>
|
||||
|
||||
<orderedlist>
|
||||
@ -299,15 +292,17 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you are running <ulink
|
||||
url="http://www.slackware.com">Slackware</ulink>, edit the install.sh
|
||||
file and change the line</para>
|
||||
<para>If you are running <ulink url="http://www.slackware.com">Slackware</ulink>,
|
||||
you should use Shorewall 2.0.2 RC1 or later. You must also edit the
|
||||
install.sh file and change the lines</para>
|
||||
|
||||
<programlisting>DEST=""</programlisting>
|
||||
<programlisting>DEST="/etc/init.d"
|
||||
INIT="shorewall"</programlisting>
|
||||
|
||||
<para>to</para>
|
||||
|
||||
<programlisting>DEST="/etc/rc.d"</programlisting>
|
||||
<programlisting>DEST="/etc/rc.d"
|
||||
INIT="rc.firewall"</programlisting>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -318,8 +313,7 @@
|
||||
|
||||
<listitem>
|
||||
<para>See if there are any incompatibilities between your
|
||||
configuration and the new Shorewall version and correct as
|
||||
necessary.</para>
|
||||
configuration and the new Shorewall version and correct as necessary.</para>
|
||||
|
||||
<programlisting><command>shorewall check</command></programlisting>
|
||||
</listitem>
|
||||
@ -333,8 +327,7 @@
|
||||
<listitem>
|
||||
<para>If the install script was unable to configure Shorewall to be
|
||||
started automatically at boot, see <ulink
|
||||
url="starting_and_stopping_shorewall.htm">these
|
||||
instructions</ulink>.</para>
|
||||
url="starting_and_stopping_shorewall.htm">these instructions</ulink>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
@ -363,7 +356,6 @@
|
||||
<section>
|
||||
<title>Uninstall/Fallback</title>
|
||||
|
||||
<para>See <quote><ulink url="fallback.htm">Fallback and
|
||||
Uninstall</ulink></quote>.</para>
|
||||
<para>See <quote><ulink url="fallback.htm">Fallback and Uninstall</ulink></quote>.</para>
|
||||
</section>
|
||||
</article>
|
||||
@ -13,7 +13,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-05-03</pubdate>
|
||||
<pubdate>2004-05-10</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -27,8 +27,7 @@
|
||||
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
|
||||
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
||||
License</ulink></quote>.</para>
|
||||
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
@ -56,9 +55,9 @@
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">DO NOT INSTALL CORRECTED COMPONENTS ON A
|
||||
RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER
|
||||
BELOW.</emphasis> For example, do NOT install the 1.3.9a firewall
|
||||
script if you are running 1.3.7c.</para>
|
||||
RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW.</emphasis>
|
||||
For example, do NOT install the 1.3.9a firewall script if you are
|
||||
running 1.3.7c.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</caution>
|
||||
@ -80,8 +79,7 @@
|
||||
<section>
|
||||
<title>Bogons File</title>
|
||||
|
||||
<para><ulink
|
||||
url="http://shorewall.net/pub/shorewall/errata/2.0.1/bogons">Here</ulink>
|
||||
<para><ulink url="http://shorewall.net/pub/shorewall/errata/2.0.1/bogons">Here</ulink>
|
||||
is the most up to date version of the <ulink
|
||||
url="Documentation.htm#Bogons">bogons file</ulink>.</para>
|
||||
</section>
|
||||
@ -98,22 +96,20 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Modules listed in /etc/shorewall/modules don't load or produce
|
||||
errors on Mandrake 10.0 Final.</para>
|
||||
<para>Modules listed in /etc/shorewall/modules don't load or
|
||||
produce errors on Mandrake 10.0 Final.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <command>shorewall delete</command> command does not
|
||||
remove all dynamic rules pertaining to the host(s) being
|
||||
deleted.</para>
|
||||
remove all dynamic rules pertaining to the host(s) being deleted.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>These problems are corrected in <ulink
|
||||
url="http://shorewall.net/pub/shorewall/errata/2.0.1/firewall">this
|
||||
firewall script</ulink> which may be installed in
|
||||
<filename>/usr/share/shorewall/firewall</filename> as described
|
||||
above.</para>
|
||||
firewall script</ulink> which may be installed in <filename>/usr/share/shorewall/firewall</filename>
|
||||
as described above.</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
@ -137,11 +133,10 @@
|
||||
url="http://shorewall.net/pub/shorewall/errata/2.0.1/init.debian.sh">this
|
||||
file</ulink> as /etc/init.d/shorewall (replacing the existing file
|
||||
with that name). If you are just installing or upgrading to
|
||||
Shorewall 2.0.0 or 2.0.1, then replace the
|
||||
<filename>init.debian.sh</filename> file in the Shorewall
|
||||
distribution directory (shorewall-2.0.x) with the updated file
|
||||
before running <command>install.sh</command> from that
|
||||
directory.</para>
|
||||
Shorewall 2.0.0 or 2.0.1, then replace the <filename>init.debian.sh</filename>
|
||||
file in the Shorewall distribution directory (shorewall-2.0.x) with
|
||||
the updated file before running <command>install.sh</command> from
|
||||
that directory.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
@ -163,13 +158,11 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>The first problem has been corrected in Shorewall update
|
||||
2.0.0a.</para>
|
||||
<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>
|
||||
firewall script</ulink> in /usr/share/shorewall as described above.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
@ -186,7 +179,8 @@
|
||||
<para>If you want to use the new features in Shorewall 2.0.2 (Betas, RCs,
|
||||
Final) or later then you need to patch your iptables 1.2.9 with <ulink
|
||||
url="http://shorewall.net/pub/shorewall/errata/iptables-1.2.9.diff">this
|
||||
patch</ulink>.</para>
|
||||
patch</ulink> or you need to use the <ulink
|
||||
url="http://www.netfilter.org/downloads.html#cvs">CVS version of iptables</ulink>.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -197,151 +191,30 @@
|
||||
--reject-with tcp-reset</quote> is broken. The symptom most commonly seen
|
||||
is that REJECT rules act just like DROP rules when dealing with TCP. A
|
||||
kernel patch and precompiled modules to fix this problem are available at
|
||||
<ulink
|
||||
url="ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel">ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel</ulink></para>
|
||||
<ulink url="ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel">ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel</ulink></para>
|
||||
|
||||
<note>
|
||||
<para>RedHat have corrected this problem in their 2.4.20-27.x
|
||||
kernels.</para>
|
||||
<para>RedHat have corrected this problem in their 2.4.20-27.x kernels.</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory>
|
||||
<revision>
|
||||
<revnumber>1.12</revnumber>
|
||||
|
||||
<date>2004-05-04</date>
|
||||
|
||||
<authorinitials>TE</authorinitials>
|
||||
|
||||
<revremark>Add Alex Wilms's "install.sh" fix.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>1.11</revnumber>
|
||||
|
||||
<date>2004-05-03</date>
|
||||
|
||||
<authorinitials>TE</authorinitials>
|
||||
|
||||
<revremark>Add Stefan Engel's "shorewall delete" fix.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>1.10</revnumber>
|
||||
|
||||
<date>2004-04-28</date>
|
||||
|
||||
<authorinitials>TE</authorinitials>
|
||||
|
||||
<revremark>Add iptables 1.2.9 iptables-save bug notice.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>1.9</revnumber>
|
||||
|
||||
<date>2004-04-21</date>
|
||||
|
||||
<authorinitials>TE</authorinitials>
|
||||
|
||||
<revremark>Debian initialization script problem. Deleted obsolete
|
||||
sections.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>1.8</revnumber>
|
||||
|
||||
<date>2004-04-20</date>
|
||||
|
||||
<authorinitials>TE</authorinitials>
|
||||
|
||||
<revremark>Updated RFC1918 and BOGONS files.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>1.7</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 note about REJECT RedHat Kernal problem being
|
||||
corrected.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>1.2</revnumber>
|
||||
|
||||
<date>2003-12-29</date>
|
||||
|
||||
<authorinitials>TE</authorinitials>
|
||||
|
||||
<revremark>Updated RFC1918 file</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>1.1</revnumber>
|
||||
|
||||
<date>2003-12-17</date>
|
||||
|
||||
<authorinitials>TE</authorinitials>
|
||||
|
||||
<revremark>Initial Conversion to Docbook XML</revremark>
|
||||
</revision>
|
||||
</revhistory></para>
|
||||
<para><revhistory><revision><revnumber>1.14</revnumber><date>2004-05-10</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
link to Netfilter CVS</revremark></revision><revision><revnumber>1.13</revnumber><date>2004-05-04</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
Alex Wilms's "install.sh" fix.</revremark></revision><revision><revnumber>1.12</revnumber><date>2004-05-03</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
Stefan Engel's "shorewall delete" fix.</revremark></revision><revision><revnumber>1.11</revnumber><date>2004-04-28</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
iptables 1.2.9 iptables-save bug notice.</revremark></revision><revision><revnumber>1.10</revnumber><date>2004-04-21</date><authorinitials>TE</authorinitials><revremark>Debian
|
||||
initialization script problem. Deleted obsolete sections.</revremark></revision><revision><revnumber>1.9</revnumber><date>2004-04-20</date><authorinitials>TE</authorinitials><revremark>Updated
|
||||
RFC1918 and BOGONS files.</revremark></revision><revision><revnumber>1.8</revnumber><date>2004-03-20</date><authorinitials>TE</authorinitials><revremark>Proxy
|
||||
ARP/IPSEC fix.</revremark></revision><revision><revnumber>1.7</revnumber><date>2004-03-17</date><authorinitials>TE</authorinitials><revremark>Action
|
||||
rules are reported as policies.</revremark></revision><revision><revnumber>1.6</revnumber><date>2004-02-03</date><authorinitials>TE</authorinitials><revremark>Update
|
||||
for Shorewall 2.0.0.</revremark></revision><revision><revnumber>1.5</revnumber><date>2004-01-19</date><authorinitials>TE</authorinitials><revremark>IPV6
|
||||
address problems. Make RFC1918 file section more prominent.</revremark></revision><revision><revnumber>1.4</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
|
||||
note about REJECT RedHat Kernal problem being corrected.</revremark></revision><revision><revnumber>1.2</revnumber><date>2003-12-29</date><authorinitials>TE</authorinitials><revremark>Updated
|
||||
RFC1918 file</revremark></revision><revision><revnumber>1.1</revnumber><date>2003-12-17</date><authorinitials>TE</authorinitials><revremark>Initial
|
||||
Conversion to Docbook XML</revremark></revision></revhistory></para>
|
||||
</appendix>
|
||||
</article>
|
||||
@ -13,7 +13,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-04-24</pubdate>
|
||||
<pubdate>2004-05-09</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2002</year>
|
||||
@ -223,6 +223,22 @@ ACCEPT <emphasis><source></emphasis> <emphasis><destination>
|
||||
ACCEPT <emphasis><source></emphasis> <emphasis><destination></emphasis> tcp 23</programlisting>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>TFTP</title>
|
||||
|
||||
<para>You must have TFTP connection tracking support in your kernel. If
|
||||
modularized, the modules are <emphasis role="bold">ip_conntrack_tftp</emphasis>
|
||||
(and <emphasis role="bold">ip_nat_tftp</emphasis> if any form of NAT is
|
||||
involved) These modules may be loaded using entries in
|
||||
<filename>/etc/shorewall/modules</filename>. The <emphasis role="bold">ip_conntrack_tftp</emphasis>
|
||||
module must be loaded first. Note that the <filename>/etc/shorewall/modules</filename>
|
||||
file released with recent Shorewall versions contains entries for these
|
||||
modules.</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <emphasis><source></emphasis> <emphasis><destination></emphasis> udp 69</programlisting>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Traceroute</title>
|
||||
|
||||
@ -280,7 +296,8 @@ ACCEPT <emphasis><source></emphasis> <emphasis><destination>
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory><revision><revnumber>1.8</revnumber><date>2004-04-24</date><authorinitials>TE</authorinitials><revremark>Revised
|
||||
<para><revhistory><revision><revnumber>1.10</revnumber><date>2004-05-09</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
TFTP.</revremark></revision><revision><revnumber>1.9</revnumber><date>2004-04-24</date><authorinitials>TE</authorinitials><revremark>Revised
|
||||
ICQ/AIM.</revremark></revision><revision><revnumber>1.8</revnumber><date>2004-04-23</date><authorinitials>TE</authorinitials><revremark>Added
|
||||
SNMP.</revremark></revision><revision><revnumber>1.7</revnumber><date>2004-02-18</date><authorinitials>TE</authorinitials><revremark>Make
|
||||
NFS work for everyone.</revremark></revision><revision><revnumber>1.6</revnumber><date>2004-02-14</date><authorinitials>TE</authorinitials><revremark>Add
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-05-04</pubdate>
|
||||
<pubdate>2004-05-10</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -29,8 +29,7 @@
|
||||
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
|
||||
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
||||
License</ulink></quote>.</para>
|
||||
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
@ -65,8 +64,13 @@
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>start -- invoked after the firewall has been started or
|
||||
restarted.</para>
|
||||
<para>initdone (added in Shorewall 2.0.2 RC1) -- invoked after Shorewall
|
||||
has flushed all existing rules but before any rules have been added to
|
||||
the builtin chains.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>start -- invoked after the firewall has been started or restarted.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -94,8 +98,8 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para><emphasis role="bold">If your version of Shorewall doesn't have the
|
||||
file that you want to use from the above list, you can simply create the
|
||||
<para><emphasis role="bold">If your version of Shorewall doesn't have
|
||||
the file that you want to use from the above list, you can simply create the
|
||||
file yourself.</emphasis> You can also supply a script with the same name as
|
||||
any of the filter chains in the firewall and the script will be invoked
|
||||
after the /etc/shorewall/rules file has been processed but before the
|
||||
@ -110,10 +114,10 @@
|
||||
<command>run_iptables</command> instead. <command>run_iptables</command>
|
||||
will run the iptables utility passing the arguments to
|
||||
<command>run_iptables</command> and if the command fails, the firewall
|
||||
will be stopped (Shorewall version < 2.0.2 Beta 1 or there is no
|
||||
will be stopped (Shorewall version < 2.0.2 Beta 1 or there is no
|
||||
<filename>/var/lib/shorewall/restore</filename> file) or restored
|
||||
(Shorewall version >= 2.0.2 Beta 1 and
|
||||
<filename>/var/lib/shorewall/restore</filename> exists).</para>
|
||||
(Shorewall version >= 2.0.2 Beta 1 and <filename>/var/lib/shorewall/restore</filename>
|
||||
exists).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -121,13 +125,11 @@
|
||||
commands other than <command>iptables</command> that must be re-run in
|
||||
order to restore the firewall to its current state then you must save
|
||||
the commands to the <firstterm>restore file</firstterm>. The restore
|
||||
file is a temporary file in <filename
|
||||
class="directory">/var/lib/shorewall</filename> that will be renamed
|
||||
<filename>/var/lib/shorewall/restore-base</filename> at the successful
|
||||
completion of the Shorewall command. The <command>shorewall
|
||||
save</command> command combines
|
||||
<filename>/var/lib/shorewall/restore-base</filename> with the output of
|
||||
<command>iptables-save</command> to produce the
|
||||
file is a temporary file in <filename class="directory">/var/lib/shorewall</filename>
|
||||
that will be renamed <filename>/var/lib/shorewall/restore-base</filename>
|
||||
at the successful completion of the Shorewall command. The
|
||||
<command>shorewall save</command> command combines <filename>/var/lib/shorewall/restore-base</filename>
|
||||
with the output of <command>iptables-save</command> to produce the
|
||||
<filename>/var/lib/shorewall/restore</filename> script.</para>
|
||||
|
||||
<para>Here are three functions that are useful when running commands
|
||||
@ -140,15 +142,15 @@
|
||||
|
||||
<para>Example: <programlisting>save_command echo Operation Complete</programlisting></para>
|
||||
|
||||
<para>That command would simply write "echo Operation Complete" to
|
||||
the restore file.</para>
|
||||
<para>That command would simply write "echo Operation
|
||||
Complete" to the restore file.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><emphasis role="bold">run_and_save_command()</emphasis> --
|
||||
saves the passed command to the restore file then executes it. The
|
||||
return value is the exit status of the command. Example:
|
||||
<programlisting>run_and_save_command "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"</programlisting></para>
|
||||
<programlisting>run_and_save_command "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"</programlisting></para>
|
||||
|
||||
<para>Note that as in this example, when the command involves file
|
||||
redirection then the entire command must be enclosed in quotes. This
|
||||
@ -158,21 +160,21 @@
|
||||
<listitem>
|
||||
<para><emphasis role="bold">ensure_and_save_command()</emphasis> --
|
||||
runs the passed command. If the command fails, the firewall is
|
||||
restored to it's prior saved state and the operation is terminated.
|
||||
If the command succeeds, the command is written to the restore
|
||||
file</para>
|
||||
restored to it's prior saved state and the operation is
|
||||
terminated. If the command succeeds, the command is written to the
|
||||
restore file</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Beginning with Shorewall 2.0.0, you can also define a <emphasis>common
|
||||
action</emphasis> to be performed immediately before a policy of ACCEPT,
|
||||
DROP or REJECT is applied. Separate <ulink
|
||||
<para>Beginning with Shorewall 2.0.0, you can also define a
|
||||
<emphasis>common action</emphasis> to be performed immediately before a
|
||||
policy of ACCEPT, DROP or REJECT is applied. Separate <ulink
|
||||
url="User_defined_Actions.html">actions</ulink> can be assigned to each
|
||||
policy type so for example you can have a different common action for DROP
|
||||
and REJECT policies. The most common usage of common actions is to silently
|
||||
drop traffic that you don't wish to have logged by the policy.</para>
|
||||
drop traffic that you don't wish to have logged by the policy.</para>
|
||||
|
||||
<para>As released, Shorewall defines a number of actions which are cataloged
|
||||
in the <filename>/usr/share/shorewall/actions.std</filename> file. That file
|
||||
@ -195,10 +197,10 @@ Reject:REJECT</programlisting>
|
||||
|
||||
<para>One final note. The chain created to perform an action has the same
|
||||
name as the action. You can use an extension script by that name to add
|
||||
rules to the action's chain in the same way as you can any other chain. So
|
||||
if you create the new action <quote>Dagger</quote> and define it in
|
||||
rules to the action's chain in the same way as you can any other chain.
|
||||
So if you create the new action <quote>Dagger</quote> and define it in
|
||||
<filename>/etc/shorewall/action.Dagger</filename>, you can also have an
|
||||
extension script named <filename>/etc/shorewall/Dagger</filename> that can
|
||||
add rules to the <quote>Dagger</quote> chain that can't be created using
|
||||
add rules to the <quote>Dagger</quote> chain that can't be created using
|
||||
<filename>/etc/shorewall/action.Dagger</filename>.</para>
|
||||
</article>
|
||||
@ -30,8 +30,7 @@
|
||||
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
|
||||
<quote><ulink type="" url="copyright.htm">GNU Free Documentation
|
||||
License</ulink></quote>.</para>
|
||||
<quote><ulink type="" url="copyright.htm">GNU Free Documentation License</ulink></quote>.</para>
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
@ -42,10 +41,10 @@
|
||||
the version number mentioned in the section title is later than what you
|
||||
are currently running.</para>
|
||||
|
||||
<para>In the descriptions that follows, the term
|
||||
<emphasis>group</emphasis> refers to a particular network or subnetwork
|
||||
(which may be <literal>0.0.0.0/0</literal> or it may be a host address)
|
||||
accessed through a particular interface.</para>
|
||||
<para>In the descriptions that follows, the term <emphasis>group</emphasis>
|
||||
refers to a particular network or subnetwork (which may be
|
||||
<literal>0.0.0.0/0</literal> or it may be a host address) accessed through
|
||||
a particular interface.</para>
|
||||
|
||||
<para>Examples:</para>
|
||||
|
||||
@ -62,7 +61,20 @@
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 2.0.2 Beta 1</title>
|
||||
<title>Version >= 2.0.2 RC1</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>If you are upgrading from Shorewall 1.4.x and you have commands
|
||||
in your <filename>/etc/shorewall/common</filename> file that are not
|
||||
directly related to the <emphasis role="bold">common</emphasis> chain
|
||||
then you will want to move those commands to <filename>/etc/shorewall/initdone</filename>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 2.0.2 Beta 1</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
@ -72,12 +84,11 @@
|
||||
scripts.</para>
|
||||
|
||||
<para>If your extension scripts are executing commands other than
|
||||
iptables then those commands must also be written to the restore file
|
||||
(a temporary file in <filename
|
||||
class="directory">/var/lib/shorewall</filename> that is renamed
|
||||
<filename>/var/lib/shorewall/restore-base</filename> at the
|
||||
completeion of the <filename>/sbin/shorewall</filename> command). The
|
||||
following functions should be of help:</para>
|
||||
<command>iptables</command> then those commands must also be written
|
||||
to the restore file (a temporary file in <filename class="directory">/var/lib/shorewall</filename>
|
||||
that is renamed <filename>/var/lib/shorewall/restore-base</filename>
|
||||
at the completeion of the <filename>/sbin/shorewall</filename>
|
||||
command). The following functions should be of help:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
@ -86,14 +97,14 @@
|
||||
|
||||
<para>Example: <programlisting>save_command echo Operation Complete</programlisting></para>
|
||||
|
||||
<para>That command would simply write "echo Operation Complete" to
|
||||
the restore file.</para>
|
||||
<para>That command would simply write "echo Operation
|
||||
Complete" to the restore file.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para> run_and_save_command() -- saves the passed command to the
|
||||
<para>run_and_save_command() -- saves the passed command to the
|
||||
restore file then executes it. The return value is the exit status
|
||||
of the command. Example: <programlisting>run_and_save_command "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"</programlisting></para>
|
||||
of the command. Example: <programlisting>run_and_save_command "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"</programlisting></para>
|
||||
|
||||
<para>Note that as in this example, when the command involves file
|
||||
redirection then the entire command must be enclosed in quotes.
|
||||
@ -102,55 +113,54 @@
|
||||
|
||||
<listitem>
|
||||
<para>ensure_and_save_command() -- runs the passed command. If the
|
||||
command fails, the firewall is restored to it's prior saved state
|
||||
and the operation is terminated. If the command succeeds, the
|
||||
command is written to the restore file</para>
|
||||
command fails, the firewall is restored to it's prior saved
|
||||
state and the operation is terminated. If the command succeeds,
|
||||
the command is written to the restore file</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Dynamic Zone support. - If you don't need to use the
|
||||
<command>shorewall add</command> and <command>shorewall
|
||||
delete</command> commands, you should set DYNAMIC_ZONES=No in
|
||||
<filename>/etc/shorewall/shorewall.conf</filename>.</para>
|
||||
<para>Dynamic Zone support. - If you don't need to use the
|
||||
<command>shorewall add</command> and <command>shorewall delete</command>
|
||||
commands, you should set DYNAMIC_ZONES=No in <filename>/etc/shorewall/shorewall.conf</filename>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 2.0.1</title>
|
||||
<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>
|
||||
<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>
|
||||
<title>VERSION >= 2.0.0-Beta1</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>The 'dropunclean' and 'logunclean' interface options are no
|
||||
longer supported. If either option is specified in
|
||||
<para>The 'dropunclean' and 'logunclean' interface
|
||||
options are no longer supported. If either option is specified in
|
||||
<filename>/etc/shorewall/interfaces</filename>, a threatening message
|
||||
will be generated.</para>
|
||||
</listitem>
|
||||
@ -159,19 +169,18 @@
|
||||
<para>The NAT_BEFORE_RULES option has been removed from
|
||||
<filename>shorewall.conf</filename>. The behavior of Shorewall 2.0 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.</para>
|
||||
rules now always take precidence over one-to-one NAT specifications.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The default value for the ALL INTERFACES column in
|
||||
<filename>/etc/shorewall/nat</filename> 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.</para>
|
||||
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.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The following files don't exist in Shorewall 2.0:</para>
|
||||
<para>The following files don't exist in Shorewall 2.0:</para>
|
||||
|
||||
<simplelist>
|
||||
<member><filename>/etc/shorewall/common.def</filename></member>
|
||||
@ -181,14 +190,13 @@
|
||||
<member><filename>/etc/shorewall/icmpdef</filename></member>
|
||||
|
||||
<member><filename>/etc/shorewall/action.template</filename> (moved
|
||||
to
|
||||
<filename>/usr/share/shorewall/action.template</filename>)</member>
|
||||
to <filename>/usr/share/shorewall/action.template</filename>)</member>
|
||||
</simplelist>
|
||||
|
||||
<para>The <filename>/etc/shorewall/action</filename> 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).</para>
|
||||
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).</para>
|
||||
|
||||
<para>The file /usr/share/shorewall/actions.std has been added to
|
||||
define those actions that are released as part of Shorewall 2.0 In
|
||||
@ -204,29 +212,28 @@
|
||||
policies while the <quote>Reject</quote> 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.</para>
|
||||
release, the difference between "Reject" and "Drop" is
|
||||
that "Reject" REJECTs SMB traffic while "Drop"
|
||||
silently drops such traffic.</para>
|
||||
|
||||
<para>As described above, Shorewall allows a common action for ACCEPT
|
||||
policies but does not specify such an action in the default
|
||||
configuration.</para>
|
||||
|
||||
<para>For more information see the <ulink
|
||||
url="User_defined_Actions.html">User-defined Action
|
||||
Page</ulink>.</para>
|
||||
url="User_defined_Actions.html">User-defined Action Page</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <filename>/etc/shorewall</filename> directory no longer
|
||||
contains <filename>users</filename> file or a
|
||||
<filename>usersets</filename> file. Similar functionality is now
|
||||
available using user-defined actions.</para>
|
||||
contains <filename>users</filename> file or a <filename>usersets</filename>
|
||||
file. Similar functionality is now available using user-defined
|
||||
actions.</para>
|
||||
|
||||
<para>Now, action files created by copying
|
||||
<filename>/usr/share/shorewall/action.template</filename> 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.</para>
|
||||
<para>Now, action files created by copying <filename>/usr/share/shorewall/action.template</filename>
|
||||
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.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -234,69 +241,64 @@
|
||||
now labeled USER/GROUP and may contain:</para>
|
||||
|
||||
<simplelist>
|
||||
<member>[!]<<emphasis>user number</emphasis>>[:]</member>
|
||||
<member>[!]<<emphasis>user number</emphasis>>[:]</member>
|
||||
|
||||
<member>[!]<<emphasis>user name</emphasis>>[:]</member>
|
||||
<member>[!]<<emphasis>user name</emphasis>>[:]</member>
|
||||
|
||||
<member>[!]:<<emphasis>group number</emphasis>></member>
|
||||
<member>[!]:<<emphasis>group number</emphasis>></member>
|
||||
|
||||
<member>[!]:<<emphasis>group name</emphasis>></member>
|
||||
<member>[!]:<<emphasis>group name</emphasis>></member>
|
||||
|
||||
<member>[!]<<emphasis>user
|
||||
number</emphasis>>:<<emphasis>group
|
||||
number</emphasis>></member>
|
||||
<member>[!]<<emphasis>user number</emphasis>>:<<emphasis>group
|
||||
number</emphasis>></member>
|
||||
|
||||
<member>[!]<<emphasis>user
|
||||
name</emphasis>>:<<emphasis>group
|
||||
number</emphasis>></member>
|
||||
<member>[!]<<emphasis>user name</emphasis>>:<<emphasis>group
|
||||
number</emphasis>></member>
|
||||
|
||||
<member>[!]<<emphasis>user
|
||||
inumber</emphasis>>:<<emphasis>group
|
||||
name</emphasis>></member>
|
||||
<member>[!]<<emphasis>user inumber</emphasis>>:<<emphasis>group
|
||||
name</emphasis>></member>
|
||||
|
||||
<member>[!]<<emphasis>user
|
||||
name</emphasis>>:<<emphasis>group name</emphasis>></member>
|
||||
<member>[!]<<emphasis>user name</emphasis>>:<<emphasis>group
|
||||
name</emphasis>></member>
|
||||
</simplelist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If your kernel has IPV6 support (recent
|
||||
<trademark>SuSe</trademark> for example), and you don't use IPV6 then
|
||||
you will probably want to set DISABLE_IPV6=Yes in <ulink
|
||||
url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>.
|
||||
<para>If your kernel has IPV6 support (recent <trademark>SuSe</trademark>
|
||||
for example), and you don't use IPV6 then you will probably want
|
||||
to set DISABLE_IPV6=Yes in <ulink url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>.
|
||||
You must have ipv6tables installed.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.4.8</title>
|
||||
<title>Version >= 1.4.8</title>
|
||||
|
||||
<itemizedlist mark="bullet">
|
||||
<listitem>
|
||||
<para>The meaning of <varname>ROUTE_FILTER=Yes</varname> has changed.
|
||||
Previously this setting was documented as causing route filtering to
|
||||
occur on all network interfaces; this didn't work. Beginning with this
|
||||
release, <varname>ROUTE_FILTER=Yes</varname> causes route filtering to
|
||||
occur on all interfaces brought up while Shorewall is running. This
|
||||
means that it may be appropriate to set
|
||||
occur on all network interfaces; this didn't work. Beginning with
|
||||
this release, <varname>ROUTE_FILTER=Yes</varname> causes route
|
||||
filtering to occur on all interfaces brought up while Shorewall is
|
||||
running. This means that it may be appropriate to set
|
||||
<varname>ROUTE_FILTER=Yes</varname> and use the routefilter option in
|
||||
<filename
|
||||
class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
||||
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
||||
entries.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.4.6</title>
|
||||
<title>Version >= 1.4.6</title>
|
||||
|
||||
<itemizedlist mark="bullet">
|
||||
<listitem>
|
||||
<para>The <varname>NAT_ENABLED</varname>,
|
||||
<varname>MANGLE_ENABLED</varname> and <varname>MULTIPORT</varname>
|
||||
options have been removed from <filename>shorewall.conf</filename>.
|
||||
These capabilities are now automatically detected by Shorewall.</para>
|
||||
<para>The <varname>NAT_ENABLED</varname>, <varname>MANGLE_ENABLED</varname>
|
||||
and <varname>MULTIPORT</varname> options have been removed from
|
||||
<filename>shorewall.conf</filename>. These capabilities are now
|
||||
automatically detected by Shorewall.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -312,48 +314,39 @@ zone eth1:192.168.1.0/24,192.168.2.0/24
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.4.4</title>
|
||||
<title>Version >= 1.4.4</title>
|
||||
|
||||
<para>If you are upgrading from 1.4.3 and have set the
|
||||
<varname>LOGMARKER</varname> variable in <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>shorewall.conf</filename>,
|
||||
<para>If you are upgrading from 1.4.3 and have set the <varname>LOGMARKER</varname>
|
||||
variable in <filename class="directory">/etc/shorewall/</filename><filename>shorewall.conf</filename>,
|
||||
then you must set the new <varname>LOGFORMAT</varname> variable
|
||||
appropriately and remove your setting of
|
||||
<varname>LOGMARKER</varname>.</para>
|
||||
appropriately and remove your setting of <varname>LOGMARKER</varname>.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version 1.4.4</title>
|
||||
|
||||
<para>If you have zone names that are 5 characters long, you may
|
||||
experience problems starting Shorewall because the
|
||||
<option>--log-prefix</option> in a logging rule is too long. Upgrade to
|
||||
Version 1.4.4a to fix this problem.</para>
|
||||
experience problems starting Shorewall because the <option>--log-prefix</option>
|
||||
in a logging rule is too long. Upgrade to Version 1.4.4a to fix this
|
||||
problem.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.4.2</title>
|
||||
<title>Version >= 1.4.2</title>
|
||||
|
||||
<para>There are some cases where you may want to handle traffic from a
|
||||
particular group to itself. While I personally think that such a setups
|
||||
are ridiculous, there are two cases covered in this documentation where it
|
||||
can occur: <itemizedlist>
|
||||
<listitem>
|
||||
<para><ulink url="FAQ.htm#faq2">In FAQ #2</ulink></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><ulink url="Shorewall_Squid_Usage.html">When running
|
||||
<application>Squid</application> as a transparent proxy in your
|
||||
local zone.</ulink></para>
|
||||
</listitem>
|
||||
</itemizedlist> If you have either of these cases, you will want to
|
||||
review the current documentation and change your configuration
|
||||
accordingly.</para>
|
||||
can occur: <itemizedlist><listitem><para><ulink url="FAQ.htm#faq2">In FAQ
|
||||
#2</ulink></para></listitem><listitem><para><ulink
|
||||
url="Shorewall_Squid_Usage.html">When running <application>Squid</application>
|
||||
as a transparent proxy in your local zone.</ulink></para></listitem></itemizedlist>
|
||||
If you have either of these cases, you will want to review the current
|
||||
documentation and change your configuration accordingly.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.4.1</title>
|
||||
<title>Version >= 1.4.1</title>
|
||||
|
||||
<itemizedlist mark="bullet">
|
||||
<listitem>
|
||||
@ -362,10 +355,11 @@ zone eth1:192.168.1.0/24,192.168.2.0/24
|
||||
was treated just like any other traffic; any matching rules were
|
||||
applied followed by enforcement of the appropriate policy. With 1.4.1
|
||||
and later versions, unless you have explicit rules for traffic from Z
|
||||
to Z or you have an explicit Z to Z policy (where "Z" is some zone)
|
||||
then traffic between the groups in zone Z will be accepted. If you do
|
||||
have one or more explicit rules for Z to Z or if you have an explicit
|
||||
Z to Z policy then the behavior is as it was in prior versions.</para>
|
||||
to Z or you have an explicit Z to Z policy (where "Z" is some
|
||||
zone) then traffic between the groups in zone Z will be accepted. If
|
||||
you do have one or more explicit rules for Z to Z or if you have an
|
||||
explicit Z to Z policy then the behavior is as it was in prior
|
||||
versions.</para>
|
||||
|
||||
<orderedlist numeration="arabic">
|
||||
<listitem>
|
||||
@ -377,29 +371,26 @@ zone eth1:192.168.1.0/24,192.168.2.0/24
|
||||
|
||||
<listitem>
|
||||
<para>If you have a Z Z DROP or Z Z REJECT policy or you have
|
||||
Z->Z rules then your configuration should not require any
|
||||
Z->Z rules then your configuration should not require any
|
||||
change.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you are currently relying on a implicit policy (one that
|
||||
has "all" in either the SOURCE or DESTINATION column) to prevent
|
||||
traffic between two interfaces to a zone Z and you have no rules
|
||||
for Z->Z then you should add an explicit DROP or REJECT policy
|
||||
for Z to Z.</para>
|
||||
has "all" in either the SOURCE or DESTINATION column) to
|
||||
prevent traffic between two interfaces to a zone Z and you have no
|
||||
rules for Z->Z then you should add an explicit DROP or REJECT
|
||||
policy for Z to Z.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Sometimes, you want two separate zones on one interface but you
|
||||
don't want Shorewall to set up any infrastructure to handle traffic
|
||||
between them. <example>
|
||||
<title>The <filename>zones</filename>,
|
||||
<filename>interfaces</filename> and, <filename>hosts</filename>
|
||||
file contents</title>
|
||||
|
||||
<programlisting>
|
||||
don't want Shorewall to set up any infrastructure to handle
|
||||
traffic between them. <example><title>The <filename>zones</filename>,
|
||||
<filename>interfaces</filename> and, <filename>hosts</filename> file
|
||||
contents</title><programlisting>
|
||||
<filename class="directory">/etc/shorewall/</filename><filename>zones</filename>
|
||||
z1 Zone1 The first Zone
|
||||
z2 Zone2 The second Zone
|
||||
@ -409,21 +400,17 @@ z2 eth1 192.168.1.255
|
||||
|
||||
<filename class="directory">/etc/shorewall/</filename><filename>hosts</filename>
|
||||
z1 eth1:192.168.1.3
|
||||
</programlisting>
|
||||
</example> Here, zone z1 is nested in zone z2 and the firewall is
|
||||
not going to be involved in any traffic between these two zones.
|
||||
Beginning with Shorewall 1.4.1, you can prevent Shorewall from setting
|
||||
up any infrastructure to handle traffic between z1 and z2 by using the
|
||||
new NONE policy: <example>
|
||||
<title>The contents of <filename>policy</filename></title>
|
||||
|
||||
<programlisting>
|
||||
</programlisting></example> Here, zone z1 is nested in zone z2 and the
|
||||
firewall is not going to be involved in any traffic between these two
|
||||
zones. Beginning with Shorewall 1.4.1, you can prevent Shorewall from
|
||||
setting up any infrastructure to handle traffic between z1 and z2 by
|
||||
using the new NONE policy: <example><title>The contents of
|
||||
<filename>policy</filename></title><programlisting>
|
||||
<filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
|
||||
z1 z2 NONE
|
||||
z2 z1 NONE
|
||||
</programlisting>
|
||||
</example> Note that NONE policies are generally used in pairs
|
||||
unless there is asymetric routing where only the traffic on one
|
||||
</programlisting></example> Note that NONE policies are generally used in
|
||||
pairs unless there is asymetric routing where only the traffic on one
|
||||
direction flows through the firewall and you are using a NONE polciy
|
||||
in the other direction.</para>
|
||||
</listitem>
|
||||
@ -436,21 +423,21 @@ z2 z1 NONE
|
||||
<itemizedlist mark="bullet">
|
||||
<listitem>
|
||||
<para>In Version 1.4.1, Shorewall will never create rules to deal with
|
||||
traffic from a given group back to itself. The
|
||||
<varname>multi</varname> interface option is no longer available so if
|
||||
you want to route traffic between two subnetworks on the same
|
||||
interface then I recommend that you upgrade to Version 1.4.2 and use
|
||||
the <varname>routeback</varname> interface or host option.</para>
|
||||
traffic from a given group back to itself. The <varname>multi</varname>
|
||||
interface option is no longer available so if you want to route
|
||||
traffic between two subnetworks on the same interface then I recommend
|
||||
that you upgrade to Version 1.4.2 and use the <varname>routeback</varname>
|
||||
interface or host option.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.4.0</title>
|
||||
<title>Version >= 1.4.0</title>
|
||||
|
||||
<important>
|
||||
<para>Shorewall >=1.4.0 requires the <command>iproute</command>
|
||||
package ('<literal>ip</literal>' utility).</para>
|
||||
<para>Shorewall >=1.4.0 requires the <command>iproute</command>
|
||||
package ('<literal>ip</literal>' utility).</para>
|
||||
</important>
|
||||
|
||||
<note>
|
||||
@ -458,89 +445,46 @@ z2 z1 NONE
|
||||
<command>iproute2</command> which will cause the upgrade of Shorewall to
|
||||
fail with the diagnostic: <synopsis>
|
||||
error: failed dependencies:iproute is needed by shorewall-1.4.0-1
|
||||
</synopsis> This may be worked around by using the
|
||||
<option>--nodeps</option> option of <command>rpm</command> (<command>rpm
|
||||
-Uvh --nodeps
|
||||
</synopsis> This may be worked around by using the <option>--nodeps</option>
|
||||
option of <command>rpm</command> (<command>rpm -Uvh --nodeps
|
||||
<filename>your_shorewall_rpm.rpm</filename></command>).</para>
|
||||
</note>
|
||||
|
||||
<para>If you are upgrading from a version < 1.4.0, then: <itemizedlist
|
||||
mark="bullet">
|
||||
<listitem>
|
||||
<para>The <varname>noping</varname> and
|
||||
<varname>forwardping</varname> interface options are no longer
|
||||
supported nor is the <varname>FORWARDPING</varname> option in
|
||||
<filename>shorewall.conf</filename>. ICMP echo-request (ping)
|
||||
packets are treated just like any other connection request and are
|
||||
subject to rules and policies.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Interface names of the form
|
||||
<varname><device>:<integer></varname> in <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
||||
now generate a Shorewall error at startup (they always have produced
|
||||
warnings in <application
|
||||
class="software">iptables</application>).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <varname>MERGE_HOSTS</varname> variable has been removed
|
||||
from <filename>shorewall.conf</filename>. Shorewall 1.4 behaves like
|
||||
1.3 did when <varname>MERGE_HOSTS=Yes</varname>; that is zone
|
||||
contents are determined by <emphasis>BOTH</emphasis> the interfaces
|
||||
and hosts files when there are entries for the zone in both
|
||||
files.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <varname>routestopped</varname> option in the interfaces
|
||||
and hosts file has been eliminated; use entries in the
|
||||
<filename>routestopped</filename> file instead.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The Shorewall 1.2 syntax for <varname>DNAT</varname> and
|
||||
<varname>REDIRECT</varname> rules is no longer accepted; you must
|
||||
convert to using the new syntax.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <varname>ALLOWRELATED</varname> variable in
|
||||
<filename>shorewall.conf</filename> is no longer supported.
|
||||
Shorewall 1.4 behavior is the same as 1.3 with
|
||||
<varname>ALLOWRELATED=Yes</varname>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Late-arriving DNS replies are now dropped by default; there is
|
||||
no need for your own <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>common</filename>
|
||||
file simply to avoid logging these packets.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <filename>firewall</filename>,
|
||||
<filename>functions</filename> and <filename>version</filename>
|
||||
files have been moved to <filename
|
||||
class="directory">/usr/share/shorewall</filename>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The <filename>icmp.def</filename> file has been removed. If
|
||||
you include it from <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>icmpdef</filename>,
|
||||
you will need to modify that file.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>If you followed the advice in FAQ #2 and call
|
||||
<varname>find_interface_address</varname> in <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>params</filename>,
|
||||
that code should be moved to <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>init</filename>.</para>
|
||||
</listitem>
|
||||
</itemizedlist></para>
|
||||
<para>If you are upgrading from a version < 1.4.0, then: <itemizedlist
|
||||
mark="bullet"><listitem><para>The <varname>noping</varname> and
|
||||
<varname>forwardping</varname> interface options are no longer supported
|
||||
nor is the <varname>FORWARDPING</varname> option in <filename>shorewall.conf</filename>.
|
||||
ICMP echo-request (ping) packets are treated just like any other
|
||||
connection request and are subject to rules and policies.</para></listitem><listitem><para>Interface
|
||||
names of the form <varname><device>:<integer></varname> in
|
||||
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
||||
now generate a Shorewall error at startup (they always have produced
|
||||
warnings in <application class="software">iptables</application>).</para></listitem><listitem><para>The
|
||||
<varname>MERGE_HOSTS</varname> variable has been removed from
|
||||
<filename>shorewall.conf</filename>. Shorewall 1.4 behaves like 1.3 did
|
||||
when <varname>MERGE_HOSTS=Yes</varname>; that is zone contents are
|
||||
determined by <emphasis>BOTH</emphasis> the interfaces and hosts files
|
||||
when there are entries for the zone in both files.</para></listitem><listitem><para>The
|
||||
<varname>routestopped</varname> option in the interfaces and hosts file
|
||||
has been eliminated; use entries in the <filename>routestopped</filename>
|
||||
file instead.</para></listitem><listitem><para>The Shorewall 1.2 syntax
|
||||
for <varname>DNAT</varname> and <varname>REDIRECT</varname> rules is no
|
||||
longer accepted; you must convert to using the new syntax.</para></listitem><listitem><para>The
|
||||
<varname>ALLOWRELATED</varname> variable in <filename>shorewall.conf</filename>
|
||||
is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with
|
||||
<varname>ALLOWRELATED=Yes</varname>.</para></listitem><listitem><para>Late-arriving
|
||||
DNS replies are now dropped by default; there is no need for your own
|
||||
<filename class="directory">/etc/shorewall/</filename><filename>common</filename>
|
||||
file simply to avoid logging these packets.</para></listitem><listitem><para>The
|
||||
<filename>firewall</filename>, <filename>functions</filename> and
|
||||
<filename>version</filename> files have been moved to <filename
|
||||
class="directory">/usr/share/shorewall</filename>.</para></listitem><listitem><para>The
|
||||
<filename>icmp.def</filename> file has been removed. If you include it
|
||||
from <filename class="directory">/etc/shorewall/</filename><filename>icmpdef</filename>,
|
||||
you will need to modify that file.</para></listitem><listitem><para>If you
|
||||
followed the advice in FAQ #2 and call <varname>find_interface_address</varname>
|
||||
in <filename class="directory">/etc/shorewall/</filename><filename>params</filename>,
|
||||
that code should be moved to <filename class="directory">/etc/shorewall/</filename><filename>init</filename>.</para></listitem></itemizedlist></para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -551,69 +495,44 @@ error: failed dependencies:iproute is needed by shorewall-1.4.0-1
|
||||
<para>The <varname>multi</varname> interface option is no longer
|
||||
supported. Shorewall will generate rules for sending packets back out
|
||||
the same interface that they arrived on in two cases: <itemizedlist
|
||||
mark="hollow">
|
||||
<listitem>
|
||||
<para>There is an <emphasis>explicit</emphasis> policy for the
|
||||
source zone to or from the destination zone. An explicit policy
|
||||
names both zones and does not use the <varname>all</varname>
|
||||
reserved word.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>There are one or more rules for traffic for the source
|
||||
zone to or from the destination zone including rules that use
|
||||
the <varname>all</varname> reserved word. Exception: if the
|
||||
source zone and destination zone are the same then the rule must
|
||||
be explicit - it must name the zone in both the
|
||||
<varname>SOURCE</varname> and <varname>DESTINATION</varname>
|
||||
columns.</para>
|
||||
</listitem>
|
||||
</itemizedlist></para>
|
||||
mark="hollow"><listitem><para>There is an <emphasis>explicit</emphasis>
|
||||
policy for the source zone to or from the destination zone. An
|
||||
explicit policy names both zones and does not use the
|
||||
<varname>all</varname> reserved word.</para></listitem><listitem><para>There
|
||||
are one or more rules for traffic for the source zone to or from the
|
||||
destination zone including rules that use the <varname>all</varname>
|
||||
reserved word. Exception: if the source zone and destination zone are
|
||||
the same then the rule must be explicit - it must name the zone in
|
||||
both the <varname>SOURCE</varname> and <varname>DESTINATION</varname>
|
||||
columns.</para></listitem></itemizedlist></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.3.14</title>
|
||||
<title>Version >= 1.3.14</title>
|
||||
|
||||
<para>Beginning in version 1.3.14, Shorewall treats entries in <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>masq</filename>
|
||||
differently. The change involves entries with an <emphasis
|
||||
role="bold">interface name</emphasis> in the <varname>SUBNET</varname>
|
||||
(second) <emphasis role="bold">column</emphasis>: <itemizedlist
|
||||
mark="bullet">
|
||||
<listitem>
|
||||
<para>Prior to 1.3.14, Shorewall would detect the FIRST subnet on
|
||||
the interface (as shown by <quote>ip addr show interface</quote>)
|
||||
and would masquerade traffic from that subnet. Any other subnets
|
||||
that routed through <literal>eth1</literal> needed their own entry
|
||||
in <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>masq</filename>
|
||||
to be masqueraded or to have <acronym>SNAT</acronym> applied.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Beginning with Shorewall 1.3.14, Shorewall uses the firewall's
|
||||
routing table to determine ALL subnets routed through the named
|
||||
interface. Traffic originating in ANY of those subnets is
|
||||
masqueraded or has SNAT applied.</para>
|
||||
</listitem>
|
||||
</itemizedlist> You will need to make a change to your configuration if:
|
||||
<orderedlist numeration="arabic">
|
||||
<listitem>
|
||||
<para>You have one or more entries in <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>masq</filename>
|
||||
with an interface name in the <varname>SUBNET</varname> (second)
|
||||
column; and</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>That interface connects to more than one subnetwork.</para>
|
||||
</listitem>
|
||||
</orderedlist> Two examples: <example label="1">
|
||||
<title>Suppose that your current config is as follows:</title>
|
||||
|
||||
<programlisting>
|
||||
differently. The change involves entries with an <emphasis role="bold">interface
|
||||
name</emphasis> in the <varname>SUBNET</varname> (second) <emphasis
|
||||
role="bold">column</emphasis>: <itemizedlist mark="bullet"><listitem><para>Prior
|
||||
to 1.3.14, Shorewall would detect the FIRST subnet on the interface (as
|
||||
shown by <quote>ip addr show interface</quote>) and would masquerade
|
||||
traffic from that subnet. Any other subnets that routed through
|
||||
<literal>eth1</literal> needed their own entry in <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>masq</filename> to
|
||||
be masqueraded or to have <acronym>SNAT</acronym> applied.</para></listitem><listitem><para>Beginning
|
||||
with Shorewall 1.3.14, Shorewall uses the firewall's routing table to
|
||||
determine ALL subnets routed through the named interface. Traffic
|
||||
originating in ANY of those subnets is masqueraded or has SNAT applied.</para></listitem></itemizedlist>
|
||||
You will need to make a change to your configuration if: <orderedlist
|
||||
numeration="arabic"><listitem><para>You have one or more entries in
|
||||
<filename class="directory">/etc/shorewall/</filename><filename>masq</filename>
|
||||
with an interface name in the <varname>SUBNET</varname> (second) column;
|
||||
and</para></listitem><listitem><para>That interface connects to more than
|
||||
one subnetwork.</para></listitem></orderedlist> Two examples: <example
|
||||
label="1"><title>Suppose that your current config is as follows:</title><programlisting>
|
||||
<!-- I added a space below the end of the config file for clarity -->
|
||||
[root@gateway test]# cat /etc/shorewall/masq
|
||||
#INTERFACE SUBNET ADDRESS
|
||||
@ -625,13 +544,10 @@ eth0 192.168.10.0/24 206.124.146.176
|
||||
192.168.1.0/24 scope link
|
||||
192.168.10.0/24 proto kernel scope link src 192.168.10.254
|
||||
[root@gateway test]#
|
||||
</programlisting>
|
||||
</example> In this case, the second entry in <filename
|
||||
</programlisting></example> In this case, the second entry in <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>masq</filename> is
|
||||
no longer required. <example label="2">
|
||||
<title>What if your current configuration is like this?</title>
|
||||
|
||||
<programlisting>
|
||||
no longer required. <example label="2"><title>What if your current
|
||||
configuration is like this?</title><programlisting>
|
||||
[root@gateway test]# cat /etc/shorewall/masq
|
||||
#INTERFACE SUBNET ADDRESS
|
||||
eth0 eth2 206.124.146.176
|
||||
@ -641,23 +557,20 @@ eth0 eth2 206.124.146.176
|
||||
192.168.1.0/24 scope link
|
||||
192.168.10.0/24 proto kernel scope link src 192.168.10.254
|
||||
[root@gateway test]#
|
||||
</programlisting>
|
||||
</example> In this case, you would want to change the entry in
|
||||
/etc/shorewall/masq to: <programlisting>
|
||||
</programlisting></example> In this case, you would want to change the
|
||||
entry in /etc/shorewall/masq to: <programlisting>
|
||||
#INTERFACE SUBNET ADDRESS
|
||||
eth0 192.168.1.0/24 206.124.146.176
|
||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||||
</programlisting> Version 1.3.14 also introduced simplified ICMP
|
||||
echo-request (ping) handling. The option
|
||||
<varname>OLD_PING_HANDLING=Yes</varname> in <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>shorewall.conf</filename>
|
||||
echo-request (ping) handling. The option <varname>OLD_PING_HANDLING=Yes</varname>
|
||||
in <filename class="directory">/etc/shorewall/</filename><filename>shorewall.conf</filename>
|
||||
is used to specify that the old (pre-1.3.14) ping handling is to be used
|
||||
(If the option is not set in your <filename
|
||||
class="directory">/etc/shorewall/</filename>shorewall.conf then
|
||||
<varname>OLD_PING_HANDLING=Yes</varname> is assumed). I don't plan on
|
||||
supporting the old handling indefinitely so I urge current users to
|
||||
migrate to using the new handling as soon as possible. See the 'Ping'
|
||||
handling documentation for details.</para>
|
||||
(If the option is not set in your <filename class="directory">/etc/shorewall/</filename>shorewall.conf
|
||||
then <varname>OLD_PING_HANDLING=Yes</varname> is assumed). I don't
|
||||
plan on supporting the old handling indefinitely so I urge current users
|
||||
to migrate to using the new handling as soon as possible. See the
|
||||
'Ping' handling documentation for details.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -675,7 +588,7 @@ rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.3.9</title>
|
||||
<title>Version >= 1.3.9</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
@ -689,23 +602,22 @@ rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.3.8</title>
|
||||
<title>Version >= 1.3.8</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>If you have a pair of firewall systems configured for failover
|
||||
or if you have asymmetric routing, you will need to modify your
|
||||
firewall setup slightly under Shorewall versions >= 1.3.8.
|
||||
Beginning with version 1.3.8, you must set
|
||||
<varname>NEWNOTSYN=Yes</varname> in your <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>shorewall.conf</filename>
|
||||
firewall setup slightly under Shorewall versions >= 1.3.8.
|
||||
Beginning with version 1.3.8, you must set <varname>NEWNOTSYN=Yes</varname>
|
||||
in your <filename class="directory">/etc/shorewall/</filename><filename>shorewall.conf</filename>
|
||||
file.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.3.7</title>
|
||||
<title>Version >= 1.3.7</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
@ -713,14 +625,14 @@ rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
|
||||
class="directory">/etc/</filename><filename>shorewall.conf</filename>
|
||||
will need to include the following rules in their <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>icmpdef</filename>
|
||||
file (creating this file if necessary): <programlisting>
|
||||
file (creating this file if necessary):
|
||||
<programlisting>
|
||||
run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
|
||||
run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
|
||||
run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
|
||||
run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
|
||||
run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
|
||||
</programlisting> Users having an <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>icmpdef</filename>
|
||||
</programlisting> Users having an <filename class="directory">/etc/shorewall/</filename><filename>icmpdef</filename>
|
||||
file may remove the <command>./etc/shorewall/icmp.def</command>
|
||||
command from that file since the <filename>icmp.def</filename> file is
|
||||
now empty.</para>
|
||||
@ -729,37 +641,24 @@ run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Upgrading Bering to Shorewall >= 1.3.3</title>
|
||||
<title>Upgrading Bering to Shorewall >= 1.3.3</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>To properly upgrade with Shorewall version 1.3.3 and later:
|
||||
<orderedlist numeration="arabic">
|
||||
<listitem>
|
||||
<para>Be sure you have a backup -- you will need to transcribe
|
||||
any Shorewall configuration changes that you have made to the
|
||||
new configuration.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Replace the <filename>shorwall.lrp</filename> package
|
||||
provided on the Bering floppy with the later one. If you did not
|
||||
obtain the later version from Jacques's site, see additional
|
||||
instructions below.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Edit the <filename
|
||||
class="directory">/var/lib/lrpkg/</filename><filename>root.exclude.list</filename>
|
||||
file and remove the <filename>/var/lib/shorewall</filename>
|
||||
entry if present. Then do not forget to backup
|
||||
<filename>root.lrp</filename>!</para>
|
||||
</listitem>
|
||||
</orderedlist> The .lrp that I release isn't set up for a
|
||||
two-interface firewall like Jacques's. You need to follow the
|
||||
instructions for setting up a two-interface firewall plus you also
|
||||
need to add the following two Bering-specific rules to <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>rules</filename>:
|
||||
<orderedlist numeration="arabic"><listitem><para>Be sure you have a
|
||||
backup -- you will need to transcribe any Shorewall configuration
|
||||
changes that you have made to the new configuration.</para></listitem><listitem><para>Replace
|
||||
the <filename>shorwall.lrp</filename> package provided on the Bering
|
||||
floppy with the later one. If you did not obtain the later version
|
||||
from Jacques's site, see additional instructions below.</para></listitem><listitem><para>Edit
|
||||
the <filename class="directory">/var/lib/lrpkg/</filename><filename>root.exclude.list</filename>
|
||||
file and remove the <filename>/var/lib/shorewall</filename> entry if
|
||||
present. Then do not forget to backup <filename>root.lrp</filename>!</para></listitem></orderedlist>
|
||||
The .lrp that I release isn't set up for a two-interface firewall
|
||||
like Jacques's. You need to follow the instructions for setting up
|
||||
a two-interface firewall plus you also need to add the following two
|
||||
Bering-specific rules to <filename class="directory">/etc/shorewall/</filename><filename>rules</filename>:
|
||||
<programlisting>
|
||||
# Bering specific rules:
|
||||
# allow loc to fw udp/53 for dnscache to work
|
||||
@ -780,55 +679,41 @@ ACCEPT loc fw tcp 80
|
||||
<para>If you have a pair of firewall systems configured for failover
|
||||
or if you have asymmetric routing, you will need to modify your
|
||||
firewall setup slightly under Shorewall versions 1.3.6 and 1.3.7
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Create the file <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>newnotsyn</filename>
|
||||
and in it add the following rule: <!-- The following code wraps off of the document. I have added the comment above the command. -->
|
||||
<programlisting>
|
||||
<orderedlist><listitem><para>Create the file <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>newnotsyn</filename>
|
||||
and in it add the following rule: <!-- The following code wraps off of the document. I have added the comment above the command. -->
|
||||
<programlisting>
|
||||
# So that the connection tracking table can be rebuilt
|
||||
# from non-SYN packets after takeover.
|
||||
run_iptables -A newnotsyn -j RETURN
|
||||
</programlisting></para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Create <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>common</filename>
|
||||
(if you don't already have that file) and include the following:
|
||||
<programlisting>
|
||||
</programlisting></para></listitem><listitem><para>Create <filename
|
||||
class="directory">/etc/shorewall/</filename><filename>common</filename>
|
||||
(if you don't already have that file) and include the following:
|
||||
<programlisting>
|
||||
#Accept Acks to rebuild connection tracking table.
|
||||
run_iptables -A common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT
|
||||
|
||||
./etc/shorewall/common.def
|
||||
</programlisting></para>
|
||||
</listitem>
|
||||
</orderedlist></para>
|
||||
</programlisting></para></listitem></orderedlist></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Versions >= 1.3.5</title>
|
||||
<title>Versions >= 1.3.5</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Some forms of pre-1.3.0 rules file syntax are no longer
|
||||
supported. <example label="1">
|
||||
<title></title>
|
||||
|
||||
<programlisting>
|
||||
supported. <example label="1"><title></title><programlisting>
|
||||
ACCEPT net loc:192.168.1.12:22 tcp 11111 - all
|
||||
</programlisting>
|
||||
</example> Must be replaced with: <programlisting>
|
||||
</programlisting></example> Must be replaced with:
|
||||
<programlisting>
|
||||
DNAT net loc:192.168.1.12:22 tcp 11111
|
||||
</programlisting> <example label="2">
|
||||
<title></title>
|
||||
|
||||
<programlisting>
|
||||
</programlisting> <example label="2"><title></title><programlisting>
|
||||
ACCEPT loc fw::3128 tcp 80 - all
|
||||
</programlisting>
|
||||
</example> Must be replaced with: <programlisting>
|
||||
</programlisting></example> Must be replaced with:
|
||||
<programlisting>
|
||||
REDIRECT loc 3128 tcp 80
|
||||
</programlisting></para>
|
||||
</listitem>
|
||||
@ -836,7 +721,7 @@ REDIRECT loc 3128 tcp 80
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.3.2</title>
|
||||
<title>Version >= 1.3.2</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user