> 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.
>
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). 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?
> FILTER_LOG_LEVEL
> Specifies the logging level; default is 'info'. To omit
> logging, specify FILTER_LOG_LEVEL=none.
>
Have this set as the default (=info)
> FILTER_DISPOSITION
> Specifies the disposition. Default is DROP and the possible
> values are DROP, A_DROP, REJECT and A_REJECT.
>
Have this set as A_DROP.
> 1) The new auditing actions and macros introduced in Beta 4 have been
> renamed by adding an underscore ('_') after the leading A. For
> example, ADrop is now A_Drop.
>
That works with the new names.
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.
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 "
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!
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!
------------------------------------------------------------------------------
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
