On 5/27/11 7:51 PM, Tom Eastep wrote: > On 5/27/11 6:11 PM, Mr Dash Four wrote: > >> That works. >> >>> 2) Network developers have discovered an exploit that allows hosts to >>> poke holes in a firewall under some circumstances. The known ways >>> to protect against the exploit are: >>> >> How do I know if I am "affected" by this? I have various "routefilter" >> options in my interfaces file (ranging from routefilter to >> routefilter=2).
If you have neither IPv6 nor routeback interfaces, then you are not affected. >> Regardless of whether I have "routefilter" or >> "routefilter=2" shorewall creates a "filter" chain with 0 references in >> it. Don't know why that is or if it is supposed to be this way? It would be deleted if you had specified a sufficient value for OPTIMIZE in shorewall.conf. But in RC1, I will add code to delete it if it isn't referenced, regardless of optimization level. >> I also found the following: >> >> 1. USE_ACTIONS is not present in the "default" shorewall.conf (the one >> supplied with either the source or the rpm file) - it needs to be added. That's good since the option was obsoleted with the release of Shorewall-perl > >> 2. There is a syntax error in man shorewall.conf (LEGACY_FASTSTART >> section) - "/etc/shorewall are compare with " should be "/etc/shorewall >> are compared with " Your two quoted strings are identical, AFAICS. But if you are complaining about the use of the plural 'are', there are multiple modification times associated with a directory (the directory and each of its subordinate directories and files). >> 3. The following problem which I reported in Beta4 is still there - >> A_ACCEPT, A_DROP and/or A_REJECT assume comments from the first action >> (normally in Drop and Reject) which calls them, which is wrong. Example: >> >> If I have A_AllowICMPs, Auth(A_REJECT) and A_DropUPnP in my Drop action >> the following chains are produced by shorewall: >> >> Chain A_ACCEPT (4 references) >> pkts bytes target prot opt in out source destination >> 0 0 AUDIT all -- * * 0.0.0.0/0 0.0.0.0/0 /* Needed ICMP types */ AUDIT >> accept >> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 /* Needed ICMP types */ >> >> Chain A_DROP (9 references) >> pkts bytes target prot opt in out source destination >> 0 0 AUDIT all -- * * 0.0.0.0/0 0.0.0.0/0 /* UPnP */ AUDIT drop >> 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 /* UPnP */ >> >> Chain A_REJECT (2 references) >> pkts bytes target prot opt in out source destination >> 0 0 AUDIT all -- * * 0.0.0.0/0 0.0.0.0/0 /* Auth */ AUDIT reject >> 0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] /* Auth */ >> >> The comments of which are, of course, utter nonsense! These should not >> be there at all! > Give that you were eager to test and I have a full-time job unrelated to networking, I released the beta without the attached patch. > >> >> 4. Not a bug, but a suggestion. >> >> Every time I upgrade shorewall I am spending time executing diff and >> peeling my eyes out to see what new options have been introduced and >> what options, if any, have been deprecated. This exercise is very much >> prone to errors and I believe there is a simpler and better solution to >> this, which could be done "automagically" without much fuss. >> >> - Create (and distribute) shorewall.conf.default, which contains all >> shorewall.conf options with their default values for the current >> shorewall version being distributed; >> >> - Create (and distribute) shorewall.conf.template which also contains >> all available options for the shorewall version being distributed, but >> lists their "values" in the following manner: >> USE_ACTIONS=$USE_ACTIONS >> LEGACY_FASTSTART=$LEGACY_FASTSTART >> ... >> >> - Create a shell script which: >> 1). simply reads shorewall.conf.default as a shell source, so that all >> "variables" listed there are "defined" and have their values loaded up. >> 2). check to see if shorewall.conf exists (from a previous shorewall >> version perhaps) and if that is the case read this file also as a shell >> source, so that the variables previously "defined" in >> shorewall.conf.default get overwritten from the existing shorewall.conf >> 3). use shorewall.conf.template to output all shorewall.conf variables >> with their values and redirect this output to shorewall.conf >> >> - Job done and I don't have to spend any more time diff-ing old and new >> shorewall configs ever! Contributions cheerfully accepted. -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 \________________________________________________
diff --git a/Shorewall/Perl/Shorewall/Rules.pm
b/Shorewall/Perl/Shorewall/Rules.pm
index 9b061df..146f41a 100644
--- a/Shorewall/Perl/Shorewall/Rules.pm
+++ b/Shorewall/Perl/Shorewall/Rules.pm
@@ -1139,6 +1139,8 @@ sub map_old_actions( $ ) {
sub ensure_audit_chain( $;$ ) {
my ( $target, $action ) = @_;
+ push_comment( '' );
+
my $ref = $filter_table->{$target};
unless ( $ref ) {
@@ -1162,6 +1164,8 @@ sub ensure_audit_chain( $;$ ) {
}
}
+ pop_comment;
+
return $target;
}
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
