Introduction to Shorewall
- This is the Shorewall 2.0 Web Site
- The information on this site
-applies only to 2.0.x releases of
+ This is the Shorewall 1.4 Web Site
+
Getting Started with Shorewall
@@ -77,20 +79,14 @@ closely match your environment and follow the step by step instructions.
href="Documentation_Index.html">Documentation
Index is a good place to start as is the Quick Search in the frame
above.
- Running Shorewall on Mandrake® with a two-interface setup?
+ Running Shorewall on Mandrake with a two-interface setup?
If so, the documentation on this
site will not apply directly
to your setup. If you want to use the documentation that you find here,
you will want to consider uninstalling what you have and installing a
setup that matches the documentation on this site. See the Two-interface QuickStart Guide for
-details.
-
- Update: I've been
-informed by Mandrake Development that this problem has been corrected
-in Mandrake 10.0 Final (the problem still exists in the 10.0 Community
-release).
-
+details.
License
This program is free software;
you can redistribute it and/or modify it
@@ -118,127 +114,211 @@ Documentation License".
Copyright © 2001-2004 Thomas M. Eastep
News
- 4/5/2004 - Shorewall 2.0.1 3/16/2004 - Shorewall 1.4.10d
-
-Problems Corrected since 2.0.0
-
+ style="border: 0px solid ; width: 28px; height: 12px;" title="">
+ Corrects one problem:
+
+
+ - Rules involving user-defined actions often resulted in a
+warning that the rule was a POLICY.
+
+
+ 2/15/2004 - Shorewall 1.4.10c
+ Corrects one problem:
+
+
+ - Entries in /etc/shorewall/tcrules with an empty USER/GROUP
+column would cause a startup error.
+
+
+ 2/12/2004 - Shorewall 1.4.10b
+ Corrects one problem:
+
+
+ - In the /etc/shorewall/masq entry “eth0:!10.1.1.150
+ 0.0.0.0/0!10.1.0.0/16 10.1.2.16”, the
+“!10.1.0.0/16” is ignored.
+
+ 2/8/2004 - Shorewall 1.4.10a
+ Corrects two problems:
+
+
+ - A problem which can cause [re]start to fail inexplicably
+while processing /etc/shorewall/masq.
+ - Interfaces using the Atheros WiFi card to use the 'maclist'
+option.
+
+
+ 1/30/2004 - Shorewall 1.4.10
+ Problems Corrected since version 1.4.9
- - Using actions in the manner recommended in the
-documentation results in a Warning that the rule is a policy.
- - When a zone on a single interface is defined using
-/etc/shorewall/hosts, superfluous rules are generated in the
-<zone>_frwd chain.
- - Thanks to Sean Mathews, a long-standing problem with Proxy
-ARP and IPSEC has been corrected. Thanks Sean!!!
- - The "shorewall show log" and "shorewall logwatch" commands
-incorrectly displayed type 3 ICMP packets.
+ - The column descriptions in the action.template file did not
+match the column headings. That has been corrected.
+ - The presence of IPV6 addresses on devices generated error
+messages during [re]start if ADD_IP_ALIASES=Yes or ADD_SNAT_ALIASES=Yes
+are specified in /etc/shorewall/shorewall.conf. These messages have
+been eliminated.
+ - The CONTINUE action in /etc/shorewall/rules now works
+correctly. A couple of problems involving rate limiting have been
+corrected. These bug fixes courtesy of Steven Jan Springl.
+ - Shorewall now tried to avoid sending an ICMP response to
+broadcasts and smurfs.
+ - Specifying "-" or "all" in the PROTO column of an action no
+longer causes a startup error.
+
-Issues when migrating from Shorewall 2.0.0 to Shorewall 2.0.1:
+Migragion Issues:
+
+ None.
-
- - 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 /usr/share/shorewall/bogons 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 /usr/share/shorewall/bogons are
-logged at the 'info' level.
-
New Features:
-
- - Support for Bridging Firewalls has been added. For details,
-see
+ - The INTERFACE column in the /etc/shorewall/masq file may
+now specify a destination list.
-http://shorewall.net/bridge.html
+Example:
+
+ #INTERFACE
+ SUBNET ADDRESS
+ eth0:192.0.2.3,192.0.2.16/28 eth1
+
+If the list begins with "!" then SNAT will occur only if the
+destination IP address is NOT included in the list.
- - Support for NETMAP has been added. NETMAP allows NAT to be
-defined between two network:
+ - Output traffic control rules (those with the firewall as
+the source) may now be qualified by the effective userid and/or
+effective group id of the program generating the output. This feature
+is courtesy of Frédéric LESPEZ.
-
-a.b.c.1 -> x.y.z.1
-
-a.b.c.2 -> x.y.z.2
-
-a.b.c.3 -> x.y.z.3
- ...
+A new USER column has been added to /etc/shorewall/tcrules. It may
+contain :
- http://shorewall.net/netmap.htm
+ [<user name or number>]:[<group
+name or number>]
+
+The colon is optional when specifying only a user.
+
+ Examples : john: / john / :users /
+john:users
- - 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".
-
-Commands affected by this are:
-
-
-shorewall -x show [ <chain>[ <chain> ...] ]
-
-shorewall -x show tos|mangle
-
-shorewall -x show nat
-
-shorewall -x status
-
-shorewall -x monitor [ <interval> ]
+ - A "detectnets" interface option has been added for entries
+in /etc/shorewall/interfaces. This option automatically taylors the
+definition of the zone named in the ZONE column to include just
+those hosts that have routes through the interface named in the
+INTERFACE column. The named interface must be UP when Shorewall is
+[re]started.
+ WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET INTERFACE!
- - Shorewall now traps two common zone definition errors:
-
- - 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.
-
-
-
+
+ 1/17/2004 - FAQ Wiki Available
+ It has been asserted that the use of CVS for maintaining the
+Shorewall documentation has been a barrier to community participation.
+To test this theory, Alex Martin has
+created a Wiki and with the help of Mike Noyes has populated the
+Wiki with the Shorewall FAQ.
+
+ 1/13/2004 - Shorewall 1.4.9
+ Problems Corrected since version 1.4.8:
+
+ - There has been a low continuing level of confusion over the
+terms "Source NAT" (SNAT) and "Static NAT". To avoid future confusion,
+all instances of "Static NAT" have been replaced with "One-to-one NAT"
+in the documentation and configuration files.
+ - The description of NEWNOTSYN in shorewall.conf has been
+reworded for clarity.
+ - Wild-card rules (those involving "all" as SOURCE or DEST)
+will no longer produce an error if they attempt to add a rule that
+would override a NONE policy. The logic for expanding these wild-card
+rules now simply skips those (SOURCE,DEST) pairs that have a NONE
+policy.
+ - DNAT rules that also specified SNAT now work reliably.
+Previously, there were cases where the SNAT specification was
+effectively ignored.
- - In the second case, the following will appear during
-"shorewall [re]start" or "shorewall check":
-
- Determining Hosts in Zones...
- ...
- Error: Invalid zone definition for zone
-<name of zone>
- Terminated
-
+
+ Migration Issues:
+ None.
+
+New Features:
+
+ - The documentation has been completely rebased to Docbook
+XML. The documentation is now released as separate HTML and XML
+packages.
- - To support bridging, the following options have been added
-to entries in /etc/shorewall/hosts:
+ - To cut down on the number of "Why are these ports closed
+rather than stealthed?" questions, the SMB-related rules in
+/etc/shorewall/common.def have been changed from 'reject' to 'DROP'.
+ - For easier identification, packets logged under the
+'norfc1918' interface option are now logged out of chains named
+'rfc1918'. Previously, such packets were logged under chains named
+'logdrop'.
+ - Distributors and developers seem to be regularly inventing
+new naming conventions for kernel modules. To avoid the need to change
+Shorewall code for each new convention, the MODULE_SUFFIX option has
+been added to shorewall.conf. MODULE_SUFFIX may be set to the suffix
+for module names in your particular distribution. If MODULE_SUFFIX is
+not set in shorewall.conf, Shorewall will use the list "o gz ko o.gz".
- norfc1918
- nobogons
- blacklist
- tcpflags
- nosmurfs
- newnotsyn
+To see what suffix is used by your distribution:
-With the exception of 'newnotsyn', these options are only useful when
-the entry refers to a bridge port.
+ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter
- Example:
+All of the files listed should have the same suffix (extension). Set
+MODULE_SUFFIX to that suffix.
- #ZONE HOST(S)
-OPTIONS
- net
-br0:eth0
-norfc1918,nobogons,blacklist,tcpflags,nosmurfs
+Examples:
+
+ If all files end in ".kzo" then set
+MODULE_SUFFIX="kzo"
+ If all files end in ".kz.o" then set
+MODULE_SUFFIX="kz.o"
+ - Support for user defined rule ACTIONS has been implemented
+through two new files:
+
+/etc/shorewall/actions - used to list the user-defined ACTIONS.
+/etc/shorewall/action.template - For each user defined <action>,
+copy this file to /etc/shorewall/action.<action> and add the
+appropriate rules for that <action>. Once an <action> has
+been defined, it may be used like any of the builtin ACTIONS (ACCEPT,
+DROP, etc.) in /etc/shorewall/rules.
+
+Example: You want an action that logs a packet at the 'info' level and
+accepts the connection.
+
+In /etc/shorewall/actions, you would add:
+
+ LogAndAccept
+
+You would then copy /etc/shorewall/action.template to
+/etc/shorewall/action.LogAndAccept and in that file, you would add the
+two
+rules:
+ LOG:info
+ ACCEPT
+
+ - The default value for NEWNOTSYN in shorewall.conf is now
+"Yes" (non-syn TCP packets that are not part of an existing connection
+are filtered according to the rules and policies rather than being
+dropped). I have made this change for two reasons:
+
+a) NEWNOTSYN=No tends to result in lots of "stuck" connections since
+any timeout during TCP session tear down results in the firewall
+dropping all of the retries.
+
+b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info resulted in
+lots of confusing messages when a connection got "stuck". While I could
+have changed the default value of LOGNEWNOTSYN to suppress logging, I
+dislike defaults that silently throw away packets.
+ - The common.def file now contains an entry that silently
+drops ICMP packets with a null source address. Ad Koster reported a
+case where these were occuring frequently as a result of a broken
+system on his external network.
@@ -279,7 +359,7 @@ please consider making a donation to the
|