Shorewall 4.4.20 is now available for download. ---------------------------------------------------------------------------- I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E ---------------------------------------------------------------------------- 1) Previously, when a device number was explicitly specified in /etc/shorewall/tcdevices, all unused numbers less than the one specified were unavailable for allocation to following entries that did not specify a number. Now, the compiler selects the lowest unallocated number when no device number is explicitly allocated. 2) Network developers have discovered an exploit that allows hosts to poke holes in a firewall. The known ways to protect against the exploit are: a) rt_filter (Shorewall''s routefilter). Only applicable to IPv4 and can''t be used with some multi-ISP configurations. b) Insert a DROP rule that prevents hairpinning (routeback). The rule must be inserted before any ESTABLISHED,RELATED firewall rules. This approach is not appropriate for bridges and other cases, where the ''routeback'' option is specified or implied. For non-routeback interfaces, Shorewall and Shorewall6 will insert a hairpin rule, provided that the routefilter option is not specified. The rule will dispose of hairpins according to the setting of two new options in shorewall.conf and shorewall6.conf: SFILTER_LOG_LEVEL Specifies the logging level; default is ''info''. To omit logging, specify FILTER_LOG_LEVEL=none. SFILTER_DISPOSITION Specifies the disposition. Default is DROP and the possible values are DROP, A_DROP, REJECT and A_REJECT. To deal with bridges and other routeback interfaces , there is now an ''sfilter'' option in /shorewall/interfaces and /etc/shorewall6/interfaces. The value of the ''sfilter'' option is a list of network addresses enclosed in in parentheses. Where only a single address is listed, the parentheses may be omitted. When a packet from a source-filtered address is received on the interface, it is disposed of based on the new SFILTER_ options described above. For a bridge or other routeback interface, you should list all of your other local networks (those networks not attached to the bridge) in the bridge''s sfilter list. Example: My DMZ is 2001:470:b:227::40/124 My local interface (br1) is a bridge. In /etc/shorewall6/interfaces, I have: #ZONE INTERFACE BROADCAST OPTIONS loc br1 - sfilter=2001:470:b:227::40/124 3) The obsolete PKTTYPE option has been removed from shorewall.conf and the associated manpage. 4) The iptables 1.4.11 release produces an error when negative numbers are specified for IPMARK mask values. Shorewall now converts such numbers to their 32-bit hex equivalent. 5) Previously, before /etc/shorewall6/params was processed, the IPv4 Shorewall libraries (/usr/share/shorewall/lib.*) were loaded rather that the IPv6 versions (/usr/share/shorewall6/lib.*). Now, the correct libraries are loaded. 6) Shorewall now sets /proc/sys/net/bridge/bridge_nf_call_iptables or /proc/sys/net/bridge/bridge_nf_call_ip6tables when there are interfaces with the ''bridge'' option. This insures that netfilter rules are invoked for bridged traffic. Previously, Shorewall was not setting these flags with the possible result that a bridge/firewall would not work properly. 7) Problem corrections released in 4.4.19.1-4.4.19.4 (see below) are also included in this release. ---------------------------------------------------------------------------- I I. K N O W N P R O B L E M S R E M A I N I N G ---------------------------------------------------------------------------- 1) On systems running Upstart, shorewall-init cannot reliably secure the firewall before interfaces are brought up. ---------------------------------------------------------------------------- I I I. N E W F E A T U R E S I N T H I S R E L E A S E ---------------------------------------------------------------------------- 1) The implementation of the environmental variables LIBEXEC and PERLLIB that was introduced in 4.4.19 has been changed slightly. The installers now allow absolute path names to be supplied in these variables so that the executables and/or Perl modules may be installed under a top-level directory other than /usr. The change is compatible with 4.4.19 in that if a relative path name is supplied, then ''/usr/'' is prepended to the supplied name. 2) A new ACCOUNTING_TABLE option has been added to shorewall.conf and shorewall6.conf. The setting determines the Netfilter table (filter or mangle) where accounting rules are created. When ACCOUNTING_TABLE=mangle, the allowable accounting file sections are: PREROUTING INPUT OUTPUT FORWARD POSTROUTING Present sections must appear in that order. 3) An NFLOG ''ACTION'' has been added to the accounting file to allow sending matching packets (or the leading part of them) to backend accounting daemons via a netlink socket. 4) A ''whitelist'' option has been added to the blacklist file. When ''whitelist'' is specified, packets/connections matching the entry are not matched against the entries which follow. No logging of whitelisted packets/connections is performed. 5) Support for the AUDIT target has been added. AUDIT is a feature of the 2.6.39 kernel and iptables 1.4.10 that allows security auditing of access decisions. The support involves the following: a) A new "AUDIT Target" capability is added and is required for auditing support. To use AUDIT support with a capabilities file, that file must be generated using this or a later release. Use ''shorewall show capabilities'' after installing this release to see if your kernel and iptables support the AUDIT target. b) In /etc/shorewall/policy''s POLICY column, the policy (and default action, if any) may be followed by '':audit'' to cause applications of the policy to be audited. This means that any NEW connection that does not match any rule in the rules file or in the applicable ''default action'' will be audited. Only ACCEPT, DROP and REJECT policies may be audited. Example: #SOURCE DEST POLICY LOG # LEVEL net fw DROP:audit It is allowed to also specify a log level on audited policies resulting in both auditing and logging. c) Three new builtin actions that may be used in the rules file, in macros and in other actions. A_ACCEPT - Audits and accepts the connection request A_DROP - Audits and drops the connection request A_REJECT - Audits and rejects A log level may be supplied with these actions to provide both auditing and logging. Example: A_ACCEPT:info loc net ... d) The BLACKLIST_DISPOSITION, MACLIST_DISPOSITION and TCP_FLAGS_DISPOSITION options may be set as follows: BLACKLIST_DISPOSITION A_DROP or A_REJECT MACLIST_DISPOSITION A_DROP A_REJECT, unless MACLIST_TABLE=mangle TCP_FLAGS_DISPOSITION A_DROP or A_REJECT e) A SMURF_DISPOSITION option has been added to shorewall.conf. The default value is DROP; if the option is set to A_DROP, then dropped smurfs are audited. f) An ''audit'' option has been added to the /etc/shorewall/blacklist file which causes the packets matching the entry to be audited. ''audit'' may not be specified together with ''whitelist''. g) The builtin actions (dropBroadcast, rejNonSyn, etc.) now support an ''audit'' parameter which causes all ACCEPT, DROP and REJECTs performed by the action to be audited. Note: The builtin actions are those actions listed in the output of ''shorewall show actions'' with names that begin with a lower-case letter. Example: #ACTION SOURCE DEST rejNonSyn(audit) net all h) There are audited versions of the standard Default Actions named A_Drop and A_Reject. Note that these audit everything that they do so you will probably want to make your own copies and modify them to only audit the packets that you care about. 6) Up to this release, the behaviors of ''start -f'' and ''restart -f'' has been inconsistent. The ''start -f'' command compares the modification times of /etc/shorewall[6] with /var/lib/shorewall[6]/restore while ''restart -f'' compares with /var/lib/shorewall[6]/firewall. To make the two consistent, a new LEGACY_FASTSTART option has been added. The default value when the option isn''t specified is LEGACY_FASTSTART=Yes which preserves the old behavior. When LEGACY_FASTSTART=No, ''start -f'' and ''restart -f'' both compare with /var/lib/shorewall[6]/firewall. 7) A ''-c'' (compile) option has been added to the ''start'' and ''restart'' commands in both Shorewall and Shorewall6. It overrides the setting of AUTOMAKE and unconditionally forces a recompilation of the configuration. When both -c and -f are specified, the result is determined by the option that appears last. 8) Shorewall and Shorewall6 no longer depend on ''make''. 9) A ''-T'' (trace) option has been added to the ''check'' and ''compile'' commands. When a warning or error message is generated, a Perl stack trace is included to aid in isolating the source of the message. 10) The Shorewall and Shorewall6 configuration files (including the samples) are now annotated with documentation from the associated manpage. The installers for these two packages support a -p (plain) option that installs unannotated versions of the packages. Both versions are available in the configfiles directory within the tarball. 11) The STATE subcolumn of the secmarks file now allows the values ''I'' which will match packets in the INVALID state, and ''NI'' which will match packets in either NEW or INVALID state. Thank you for using Shorewall, -The Shorewall Team -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation''s a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering''s about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
Hi Tom; Am Sonntag, 5. Juni 2011, um 18:32:28 schrieb Tom Eastep:> 2) Network developers have discovered an exploit that allows hosts to > poke holes in a firewall. The known ways to protect against the > exploit are: > > a) rt_filter (Shorewall''s routefilter). Only applicable to IPv4 > and can''t be used with some multi-ISP configurations. > > b) Insert a DROP rule that prevents hairpinning (routeback). The > rule must be inserted before any ESTABLISHED,RELATED firewall > rules. This approach is not appropriate for bridges and other > cases, where the ''routeback'' option is specified or implied. > > For non-routeback interfaces, Shorewall and Shorewall6 will insert > a hairpin rule, provided that the routefilter option is not > specified. The rule will dispose of hairpins according to the > setting of two new options in shorewall.conf and shorewall6.conf: > > SFILTER_LOG_LEVEL > Specifies the logging level; default is ''info''. To omit > logging, specify FILTER_LOG_LEVEL=none. > > > SFILTER_DISPOSITION > Specifies the disposition. Default is DROP and the possible > values are DROP, A_DROP, REJECT and A_REJECT. > > To deal with bridges and other routeback interfaces , there is now > an ''sfilter'' option in /shorewall/interfaces and > /etc/shorewall6/interfaces. > > The value of the ''sfilter'' option is a list of network addresses > enclosed in in parentheses. Where only a single address is listed, > the parentheses may be omitted. When a packet from a > source-filtered address is received on the interface, it is > disposed of based on the new SFILTER_ options described above. > > For a bridge or other routeback interface, you should list all of > your other local networks (those networks not attached to the > bridge) in the bridge''s sfilter list.I''m a bit puzzled. Can you provide a link to a more in-depth description? Does that mean all shorewall versions <= 4.4.19 are affected? thx kp ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation''s a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering''s about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
On 6/5/11 11:03 AM, KP Kirchdoerfer wrote:> Hi Tom; > > Am Sonntag, 5. Juni 2011, um 18:32:28 schrieb Tom Eastep: >> 2) Network developers have discovered an exploit that allows hosts to >> poke holes in a firewall. The known ways to protect against the >> exploit are: >> >> a) rt_filter (Shorewall''s routefilter). Only applicable to IPv4 >> and can''t be used with some multi-ISP configurations. >> >> b) Insert a DROP rule that prevents hairpinning (routeback). The >> rule must be inserted before any ESTABLISHED,RELATED firewall >> rules. This approach is not appropriate for bridges and other >> cases, where the ''routeback'' option is specified or implied. >> >> For non-routeback interfaces, Shorewall and Shorewall6 will insert >> a hairpin rule, provided that the routefilter option is not >> specified. The rule will dispose of hairpins according to the >> setting of two new options in shorewall.conf and shorewall6.conf: >> >> SFILTER_LOG_LEVEL >> Specifies the logging level; default is ''info''. To omit >> logging, specify FILTER_LOG_LEVEL=none. >> >> >> SFILTER_DISPOSITION >> Specifies the disposition. Default is DROP and the possible >> values are DROP, A_DROP, REJECT and A_REJECT. >> >> To deal with bridges and other routeback interfaces , there is now >> an ''sfilter'' option in /shorewall/interfaces and >> /etc/shorewall6/interfaces. >> >> The value of the ''sfilter'' option is a list of network addresses >> enclosed in in parentheses. Where only a single address is listed, >> the parentheses may be omitted. When a packet from a >> source-filtered address is received on the interface, it is >> disposed of based on the new SFILTER_ options described above. >> >> For a bridge or other routeback interface, you should list all of >> your other local networks (those networks not attached to the >> bridge) in the bridge''s sfilter list. > > I''m a bit puzzled. > > Can you provide a link to a more in-depth description?The details have not yet been made public.> Does that mean all shorewall versions <= 4.4.19 are affected?Only those who don''t specify ''routefilter'' on their interfaces. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation''s a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering''s about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
On 06/05/2011 11:33 AM, Tom Eastep wrote:> On 6/5/11 11:03 AM, KP Kirchdoerfer wrote: >> Am Sonntag, 5. Juni 2011, um 18:32:28 schrieb Tom Eastep: >>> 2) Network developers have discovered an exploit that allows hosts to >>> poke holes in a firewall. The known ways to protect against the >>> exploit are: > > The details have not yet been made public.Perhaps you can spare one detail. By "hosts", do you mean: local hosts, or, remote hosts? If local hosts, the impact is minor, it would basically be equivalent to UPnP (which is already running intentionally on many home networks). If remote hosts, then it''s a huge hole! I''m *really* hoping it''s not remote hosts. It''s understandable that such an exploit would not be public yet. Is there a CVE number for it yet? Is the exploit fixed in the latest kernel? I''m wondering if upgrading to 3.0.0 would have the fix in it or not? (I''m guessing this isn''t public either, because if vulnerable/invulnerable version numbers were announced, then somebody could just diff the kernel sources between them, and learn the exact details of the exploit.) Thanks! Josh ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation''s a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering''s about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
On 06/05/2011 10:33 PM, Josh Lehan wrote:> On 06/05/2011 11:33 AM, Tom Eastep wrote:ploit are:>> >> The details have not yet been made public. > > Perhaps you can spare one detail. By "hosts", do you mean: local hosts, > or, remote hosts?Provided that you use NAT, ''hosts'' means local hosts. And the ''holes'' that can be created are only to internal hosts with very specific charactristics.> > If local hosts, the impact is minor, it would basically be equivalent to > UPnP (which is already running intentionally on many home networks). >The vast majority of home networks are not vulnerable because of my point above.> If remote hosts, then it''s a huge hole! I''m *really* hoping it''s not > remote hosts. > > It''s understandable that such an exploit would not be public yet. Is > there a CVE number for it yet?I don''t see one. The research is being made public tomorrow when there should be a lot more information available.> > Is the exploit fixed in the latest kernel?No -- I am of the opinion that the problem must be addressed by firewall/IP configuration and not in the kernel.> I''m wondering if upgrading > to 3.0.0 would have the fix in it or not? (I''m guessing this isn''t > public either, because if vulnerable/invulnerable version numbers were > announced, then somebody could just diff the kernel sources between > them, and learn the exact details of the exploit.)BUT REMEMBER -- there is a simple defense; just specify ''routefilter'' on all of your IPv4 interfaces and you are perfectly safe. It is only IPv6 users and users whose external interface is a bridge that need this new Shorewall/Shorewall6 feature. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation''s a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering''s about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
> BUT REMEMBER -- there is a simple defense; just specify ''routefilter'' on > all of your IPv4 interfaces and you are perfectly safe. It is only IPv6 > users and users whose external interface is a bridge that need this new > Shorewall/Shorewall6 feature. >That bit above is particularly helpful and puts it, quite simply, in a nutshell. If details of this are going to be made public tomorrow, would you post what is published (or at least point to a link where this is done)? I am fairly interested to see what the actual issue is! ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation''s a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering''s about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
> That bit above is particularly helpful and puts it, quite simply, in a > nutshell. If details of this are going to be made public tomorrow, > would you post what is published (or at least point to a link where > this is done)? I am fairly interested to see what the actual issue is!Related to this - what does "routefilter[=2]" option in interfaces actually does in terms of iptables statements? ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation''s a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering''s about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
On 06/06/2011 06:53 AM, Mr Dash Four wrote:> >> That bit above is particularly helpful and puts it, quite simply, in a >> nutshell. If details of this are going to be made public tomorrow, >> would you post what is published (or at least point to a link where >> this is done)? I am fairly interested to see what the actual issue is! > Related to this - what does "routefilter[=2]" option in interfaces > actually does in terms of iptables statements?From Documentation/networking/ip_sysctl.txt: rp_filter - INTEGER 0 - No source validation. 1 - Strict mode as defined in RFC3704 Strict Reverse Path Each incoming packet is tested against the FIB and if the interface is not the best reverse path the packet check will fail. By default failed packets are discarded. 2 - Loose mode as defined in RFC3704 Loose Reverse Path Each incoming packet''s source address is also tested against the FIB and if the source address is not reachable via any interface the packet check will fail. Current recommended practice in RFC3704 is to enable strict mode to prevent IP spoofing from DDos attacks. If using asymmetric routing or other complicated routing, then loose mode is recommended. conf/all/rp_filter must also be set to non-zero to do source validation on the interface Default value is 0. Note that some distributions enable it in startup scripts. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation''s a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering''s about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
> From Documentation/networking/ip_sysctl.txt: > > rp_filter - INTEGER > 0 - No source validation. > 1 - Strict mode as defined in RFC3704 Strict Reverse Path > Each incoming packet is tested against the FIB and if the > interface is not the best reverse path the packet check > will fail. > By default failed packets are discarded. > 2 - Loose mode as defined in RFC3704 Loose Reverse Path > Each incoming packet''s source address is also tested > against the FIB and if the source address is not reachable > via any interface the packet check will fail. > > Current recommended practice in RFC3704 is to enable strict mode > to prevent IP spoofing from DDos attacks. If using asymmetric > routing or other complicated routing, then loose mode is > recommended. > > conf/all/rp_filter must also be set to non-zero to do source > validation on the interface > > Default value is 0. Note that some distributions enable it > in startup scripts. >Interesting read, thanks! So, I am better off with routefilter=1 than routefilter=2 as the checks applied are more stringent? There was another reason I asked this question - I need to know what to do with my other machines where no shorewall (but other) firewall is deployed? ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation''s a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering''s about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
On 06/06/2011 07:08 AM, Mr Dash Four wrote:> >> From Documentation/networking/ip_sysctl.txt: >> >> rp_filter - INTEGER >> 0 - No source validation. >> 1 - Strict mode as defined in RFC3704 Strict Reverse Path >> Each incoming packet is tested against the FIB and if the >> interface is not the best reverse path the packet check >> will fail. >> By default failed packets are discarded. >> 2 - Loose mode as defined in RFC3704 Loose Reverse Path >> Each incoming packet''s source address is also tested >> against the FIB and if the source address is not reachable >> via any interface the packet check will fail. >> >> Current recommended practice in RFC3704 is to enable strict mode >> to prevent IP spoofing from DDos attacks. If using asymmetric >> routing or other complicated routing, then loose mode is >> recommended. >> >> conf/all/rp_filter must also be set to non-zero to do source >> validation on the interface >> >> Default value is 0. Note that some distributions enable it >> in startup scripts. >> > Interesting read, thanks! So, I am better off with routefilter=1 than > routefilter=2 as the checks applied are more stringent? There was > another reason I asked this question - I need to know what to do with my > other machines where no shorewall (but other) firewall is deployed?Set /proc/sys/net/ipv4/conf/all/rp_filter = 1 Set /proc/sys/net/ipv4/conf/iface/rp_filter = 1 (for each ''iface''). -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation''s a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering''s about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
> Thank you for using Shorewall, > -The Shorewall Team >A couple of queries: 1. In .20 there is a new option in compiler.pl called "--confess". What is the purpose of it? I already know what FAKE_AUDIT does. 2. In both Drop and Reject default actions there is Auth(REJECT). Shouldn''t that be Auth(DROP) in the Drop action instead? 3. Is AUTOMAKE=Yes reliable if my files are in a non-standard shorewall directory (i.e. not in /etc/shorewall), but still in shorewall''s path? I have a "placeholder" INCLUDE statement in /etc/shorewall.conf which redirects everything in my custom path where all of my configuration files are (including a "shorewall.conf" file) so I am not sure whether AUTOMAKE=yes would work if I activate that option as the help specifically refers to files in /etc/shorewall. ------------------------------------------------------------------------------ EditLive Enterprise is the world''s most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
On 6/7/11 6:53 AM, Mr Dash Four wrote:> >> Thank you for using Shorewall, >> -The Shorewall Team >> > A couple of queries: > > 1. In .20 there is a new option in compiler.pl called "--confess". What > is the purpose of it? I already know what FAKE_AUDIT does.--confess is what gets set when the new -T option is specified in ''check'', ''compile'', etc.> 2. In both Drop and Reject default actions there is Auth(REJECT). > Shouldn''t that be Auth(DROP) in the Drop action instead?Dropping AUTH can cause connection issues with (antiquated) servers that still use it. So the default is to REJECT it; see Shorewall FAQ 4.> 3. Is AUTOMAKE=Yes reliable if my files are in a non-standard shorewall > directory (i.e. not in /etc/shorewall), but still in shorewall''s path?Not currently. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ EditLive Enterprise is the world''s most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
> --confess is what gets set when the new -T option is specified in > ''check'', ''compile'', etc. >Yeah, I did try it and I''ve got a long stack trace, which was rather nice I thought.>> 2. In both Drop and Reject default actions there is Auth(REJECT). >> Shouldn''t that be Auth(DROP) in the Drop action instead? >> > > Dropping AUTH can cause connection issues with (antiquated) servers that > still use it. So the default is to REJECT it; see Shorewall FAQ 4. >Ah, OK, makes sense, so I''ll keep it then.>> 3. Is AUTOMAKE=Yes reliable if my files are in a non-standard shorewall >> directory (i.e. not in /etc/shorewall), but still in shorewall''s path? >> > > Not currently. >Are there any plans to correct this (I assume the challenging bit is to crawl through the files in the entire path and check their modification dates)? ------------------------------------------------------------------------------ EditLive Enterprise is the world''s most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
On 6/7/11 7:16 AM, Mr Dash Four wrote:>>> 3. Is AUTOMAKE=Yes reliable if my files are in a non-standard shorewall >>> directory (i.e. not in /etc/shorewall), but still in shorewall''s path? >>> >> >> Not currently. >> > Are there any plans to correct this (I assume the challenging bit is to > crawl through the files in the entire path and check their modification > dates)?Yes -- it''s not difficult and I''ll put in on the list for 4.4.21. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ EditLive Enterprise is the world''s most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
> Yes -- it''s not difficult and I''ll put in on the list for 4.4.21. >Thanks, that would be nice as I currently have set this to "No" as I wasn''t certain it would pick up my plethora of files in the other (non-standard) location. ------------------------------------------------------------------------------ EditLive Enterprise is the world''s most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
On 06/07/2011 07:28 AM, Mr Dash Four wrote:> >> Yes -- it''s not difficult and I''ll put in on the list for 4.4.21. >> > Thanks, that would be nice as I currently have set this to "No" as I > wasn''t certain it would pick up my plethora of files in the other > (non-standard) location.Here is a lightly tested patch. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ EditLive Enterprise is the world''s most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
> Here is a lightly tested patch. >I''ll give it a go tonight when I recompile shorewall. ------------------------------------------------------------------------------ EditLive Enterprise is the world''s most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev