Hi Tom & others, I''ve been contemplating the logging tips i recommend to people to give them maximum information in their log messages (http://linuxman.wikispaces.com/PPPPPPS), and i wonder whether it would be possible to do this automatically now that shorewall-perl is with us. I was writing some configs for one of my clients and started thinking about how i could make their policies easier to understand. I came up with a perl hack that was fairly trivial, and after looking at Policy.pm, it seems to me that we could add a fairly simple config item (i was thinking to call it "EXPAND_POLICIES") that would jump in somewhere near the IMPLICIT_CONTINUE handling and simply add a policy for xxx2yyy that matched the xxx2all policy (for each of the other zones). Would you be open to a patch for this? Before the 4.0.0 release? Pretty please? :-) -- Paul <http://paulgear.webhop.net> -- Did you know? Using accepted quoting conventions makes your email easier to understand. Learn how at <http://www.netmeister.org/news/learn2quote.html>. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Paul Gear wrote:> > Would you be open to a patch for this? Before the 4.0.0 release? > Pretty please? :-) >Hi Paul, I''ll be open to a patch after 4.0.0 is released and will happily include it in 4.0.1 or 4.0.2. I don''t plan another 4.0.0 release candidate since there have been no RC2 problems reported to date (in fact, SVN has already been updated with version "4.0.0"). And even if I were to have another RC, it rather stretches the concept of "release candidate" if an RC introduces features not included in the prior one. So I mark the release of RC1 as the feature freeze point. Additionally, I don''t think the patch is a trivial one. If EXPAND_POLICIES is specified, the flow of the bottom half of the ''while ( read_a_line )'' block in validate_policy() needs to be rather different. The current code focuses on the single ''all2...'' or ''...2all'' policy chain[1], and applies that policy chain to canonical chains[2] as appropriate. With EXPAND_POLICIES, you want to: - designate all of those canonical chains as their own policy chain ( if they aren''t already) - apply the appropriate log level, default action, and syn params to the canonical chain (again, if it wasn''t a policy chain already). - avoid creating the ''all2...'' or ''...2all'' policy chain at all. You still want the ''all2...''/''...2all'' entry in the chain table though so that complete_standard_chain() can apply the most appropriate policy for INPUT, OUTPUT and FORWARD. The chains should not be listed in the @policy_chains array. Cheers, -Tom [1] - ''Policy chain'' is the chain that applies a given policy. Beware that in some of the comments in the source, ''Policy chain'' can mean an ''all2...'' or ''...2all'' chain only (although I think such usage is more common in the shorewall-shell source than in the shorewall-perl source). [2] - Canonical chain is the ''z12z2'' chain that handles traffic from zone z1 to zone z2. Each canonical chain has an associated policy chain (which may be the canonical chain itself) except when the policy is ACCEPT, NONE or CONTINUE. -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Tom Eastep wrote:> > Additionally, I don''t think the patch is a trivial one. >So the basic patch (attached) *is* pretty trivial but it suffers from one anomaly. If I place this in /etc/shorewall/policy: net all DROP info 20/sec:40 then I expect to limit the aggregate TCP connection rate from the ''net'' zone to 20/sec with a burst of 40 connections. With the attached patch, each individual net->zone connection rate is limited in that way. Fixing that problem is left as an exercise for the reader ;-) -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Tom Eastep wrote:> Tom Eastep wrote: > >> Additionally, I don''t think the patch is a trivial one. >> > > So the basic patch (attached) *is* pretty trivial but it suffers from one > anomaly. > > If I place this in /etc/shorewall/policy: > > net all DROP info 20/sec:40 > > then I expect to limit the aggregate TCP connection rate from the ''net'' zone > to 20/sec with a burst of 40 connections. > > With the attached patch, each individual net->zone connection rate is > limited in that way. > > Fixing that problem is left as an exercise for the reader ;-)The attached fixes that problem as well as several problems in the original patch. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Eastep wrote:> The attached fixes that problem as well as several problems in the original > patch.I didn''t actually check patch but I find this idea very good. If no other reason but logging gets very much easier to read if there is actually source and destination zones in logging message. Especially when using overlapping zones.... If used zones are in logging it makes it very much simpler to find out problmes when packet hits policy of underlying zone instead of correct rule. - -- Tuomo Soini <tis@foobar.fi> Linux and network services +358 40 5240030 Foobar Oy <http://foobar.fi/> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFGobXFTlrZKzwul1ERAshtAJ0Z0Z5MGX9/A9vNcSzuCst/XELFUwCePy2r xqkT6J21mtgliiXZSFqEo4k=qqHz -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Tuomo Soini wrote:> > If used zones are in logging it makes it very much simpler to find out > problmes when packet hits policy of underlying zone instead of correct rule. >A version of the patch has been applied to SVN trunk and will be included in Shorewall 4.0.1. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/