Beta 3 is now available for testing.
Summary of Beta 3:
----------------------------------------------------------------------------
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
----------------------------------------------------------------------------
All bug fixes from 4.4.19.1 - 4.4.19.4.
----------------------------------------------------------------------------
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 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 name.
2) A new ACCOUNTING_TABLE option has been added to shorewall.conf and
shorwall6.conf. The setting determines the Netfilter table (filter
or mangle) where accounting rules are created.
When ACCOUNTING_TABLE=mangle, the allowable sections in the
accounting file are as follows:
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/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
application of the policy to 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 entryto be audited. ''audit'' may not be specified
together
with ''accept''.
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. This allows creation of
audited versions of the Shorewall-provided default actions
(action.Drop and action.Reject).
Note: The builtin actions are those actions listed in the
output of ''shorewall show actions'' whose names begin with a
lower-case letter.
Thank you for testing,
-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 \________________________________________________
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
> Summary of Beta 3: > > [...] > > 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. This allows creation of > audited versions of the Shorewall-provided default actions > (action.Drop and action.Reject). > > Note: The builtin actions are those actions listed in the > output of ''shorewall show actions'' whose names begin with a > lower-case letter. >How do I utilise this (I don''t have/use any of these actions as far as I know, but they are still included in my chains)? Otherwise, pretty extensive changes which I would be able to test through as soon as I get out of the rut I am in at present. You were also planning to introduce "random-generated-and-unused" number allocated to devices - for use in tcdevices, do you remember?> Thank you for testing, >I''ll do some testing tomorrow, hopefully! ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On May 22, 2011, at 9:23 AM, Mr Dash Four wrote:> >> Summary of Beta 3: >> >> [...] >> >> 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. This allows creation of >> audited versions of the Shorewall-provided default actions >> (action.Drop and action.Reject). >> >> Note: The builtin actions are those actions listed in the >> output of ''shorewall show actions'' whose names begin with a >> lower-case letter. >> > How do I utilise this (I don''t have/use any of these actions as far as I > know, but they are still included in my chains)?Read: http://www.shorewall.net/Actions.html#Default http://www.shorewall.net/Audit.html> Otherwise, pretty > extensive changes which I would be able to test through as soon as I get > out of the rut I am in at present. You were also planning to introduce > "random-generated-and-unused" number allocated to devices - for use in > tcdevices, do you remember?I remember you complaining about the current algorithm.> I''ll do some testing tomorrow, hopefully!Thanks 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 \________________________________________________ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
> Read: > > http://www.shorewall.net/Actions.html#Default > http://www.shorewall.net/Audit.html >That was quick! A few comments/corrections though: Thomas Graf did not release the audit daemon (auditd) - the daemon was already present and is an essential part of the Linux (safe) reporting infrastructure (it reports all security-related events, not just from netfilter - that is the beauty of it all). The following paragraph, explaining what AUDIT is for, and its possible uses, was by Eric Paris (also from RedHat), which you may remember from our little debate about the secctx field being introduced in /proc/net a while ago. In point f) (http://www.shorewall.net/Audit.html) you explain how action.Drop could be utilised to use audit - is this the physical file "action.Drop" I need to amend/look at or is there something else?> I remember you complaining about the current algorithm. >The current algorithm is flawed as if I have a device "0ff" shorewall would increase that number by 1 if I have a device defined in tcdevices after that statement - that gets over the limit of "ff" and then shorewall complains and I get an error. It is better to use random unused number, or, start from 1 and check for presence and use it if unused - that''s how I see it anyway! ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
On May 22, 2011, at 9:58 AM, Mr Dash Four wrote:> >> Read: >> >> http://www.shorewall.net/Actions.html#Default >> http://www.shorewall.net/Audit.html >> > That was quick! A few comments/corrections though: Thomas Graf did not > release the audit daemon (auditd) - the daemon was already present and > is an essential part of the Linux (safe) reporting infrastructure (it > reports all security-related events, not just from netfilter - that is > the beauty of it all). > > The following paragraph, explaining what AUDIT is for, and its possible > uses, was by Eric Paris (also from RedHat), which you may remember from > our little debate about the secctx field being introduced in /proc/net a > while ago.Thanks.> > In point f) (http://www.shorewall.net/Audit.html) you explain how > action.Drop could be utilised to use audit - is this the physical file > "action.Drop" I need to amend/look at or is there something else? >I would - Copy the file somewhere else on your CONFIG_PATH (http://www.shorewall.net/configuration_file_basics.htm#CONFIG_PATH) - Rename the copy to avoid confusion - Modify the copy as needed. You might also need to copy macros like macro.SMB that are invoked by the action if you want audited copies of those as well - Modify shorewall.conf (DROP_DEFAULT) to name the copy You may also want to do that for action.Reject if you want auditing of any REJECT policy enforcement.>> I remember you complaining about the current algorithm. >> > The current algorithm is flawed as if I have a device "0ff" shorewall > would increase that number by 1 if I have a device defined in tcdevices > after that statement - that gets over the limit of "ff" and then > shorewall complains and I get an error. It is better to use random > unused number, or, start from 1 and check for presence and use it if > unused - that''s how I see it anyway!Patch attached. 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 \________________________________________________ ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay
Tom The attached config. produces the following error message: ERROR: Internal error in Shorewall::Chains::new_chain at /usr/share/shorewall/Shorewall/Chains.pm line 1200 ----------------------------------------------------------------------------------------------- In the attached config action.sjs contains 2 PERMIT statements. If the first is commented out and the second uncommented the following error messages are produced: Use of uninitialized value in numeric gt (>) at /usr/share/shorewall/Shorewall/Chains.pm line 814. ERROR: Internal error in Shorewall::Chains::decrement_reference_count at /usr/share/shorewall/Shorewall/Chains.pm line 814 Steven. ------------------------------------------------------------------------------ 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
>> In point f) (http://www.shorewall.net/Audit.html) you explain how >> action.Drop could be utilised to use audit - is this the physical file >> "action.Drop" I need to amend/look at or is there something else? >> >> > > I would > > - Copy the file somewhere else on your CONFIG_PATH (http://www.shorewall.net/configuration_file_basics.htm#CONFIG_PATH) > - Rename the copy to avoid confusion > - Modify the copy as needed. You might also need to copy macros like macro.SMB that are invoked by the action if you want audited copies of those as well > - Modify shorewall.conf (DROP_DEFAULT) to name the copy > > You may also want to do that for action.Reject if you want auditing of any REJECT policy enforcement. >This is hilarious this is! OK, this is what I''ve done: 1. I''ve copied /usr/share/shorewall/action.Drop and /usr/share/shorewall/action.Reject to /etc/shorewall as they were the only two action.* files in that directory (I left actions.std in /usr/share/shorewall) 2. mv /etc/shorewall/action.Drop /etc/shorewall/action.ADrop && mv /etc/shorewall/action.Reject /etc/shorewall/action.AReject 3. Edited shorewall.conf to change DROP_DEFAULT="ADrop" and REJECT_DEFAULT="AReject" (/etc/shorewall is in my CONFIG_PATH) 4. "shorewall check" gives me "ERROR: Default Action DROP_DEFAULT=ADrop not found" 5. I then figured shorewall must be treating ADrop as a "user-defined" action which needs to be listed in actions. So, I added "ADrop # replaces the default Drop action" and "AReject # replaces the default Reject action" to /etc/shorewall/actions 6. Ran "shorewall check" again and got this "ERROR: Internal error in Shorewall::Chains::new_chain at /usr/share/shorewall/Shorewall/Chains.pm line 1200" This was after building the latest Beta3 with your DEVNUM.patch applied. The patch works, though I have a suggestion: a device as defined in tcclasses has (automatically or not) defined value in hex, but the error message(s) produced by shorewall which relate to that device refer to this number using decimal, not hex! I think there should be a consistency and report everything in hex. Now, I am still completely in the dark where the definitions of all the allowBcast, allowInvalid, allowinUPnP, allowoutUPnP, dropBcast, dropInvalid, dropNotSyn, forwardUPnP and rejNotSyn are so that I could add the "audit" option allowing auditing. My ultimate goal also is to be able to control all the auto-generated chains with the names of the above actions so that I could audit those - I take it after redefining the above actions this is what would happen. ------------------------------------------------------------------------------ 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
> 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 >I''ve just tested this (with the exception of MACLIST_DISPOSITION), though I do not know why I can''t disable the logging (to the syslog) as the tcpflags chain is as follows: Chain logflags (5 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 4 level 6 prefix `Shorewall:logflags:A_DROP:'' 0 0 AUDIT all -- * * 0.0.0.0/0 0.0.0.0/0 AUDIT drop 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Is there a way I could get rid of the first statement?> 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. >Two things: Chain smurfs (2 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- * * 0.0.0.0 0.0.0.0/0 0 0 smurflog all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] ADDRTYPE match src-type BROADCAST 0 0 smurflog all -- * * 224.0.0.0/4 0.0.0.0/0 [goto] I can''t see a way in which there will ever be a jump to smurflog! What is causing this? Also, the same comment as with logflags above: Chain smurflog (2 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:'' 0 0 AUDIT all -- * * 0.0.0.0/0 0.0.0.0/0 AUDIT drop 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Is there a way to get rid of the LOG statement?> f) An ''audit'' option has been added to the > /etc/shorewall/blacklist file which causes the packets matching > the entryto be audited. ''audit'' may not be specified together > with ''accept''. >That works beautifully!> 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. This allows creation of > audited versions of the Shorewall-provided default actions > (action.Drop and action.Reject). > > Note: The builtin actions are those actions listed in the > output of ''shorewall show actions'' whose names begin with a > lower-case letter. >This I covered in my previous post. ------------------------------------------------------------------------------ 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
On 5/23/11 4:12 PM, Steven Jan Springl wrote:> The attached config. produces the following error message: > > ERROR: Internal error in Shorewall::Chains::new_chain > at /usr/share/shorewall/Shorewall/Chains.pm line 1200 > > ----------------------------------------------------------------------------------------------- > > In the attached config action.sjs contains 2 PERMIT statements. > If the first is commented out and the second uncommented the following error > messages are produced: > > Use of uninitialized value in numeric gt (>) > at /usr/share/shorewall/Shorewall/Chains.pm line 814. > > ERROR: Internal error in Shorewall::Chains::decrement_reference_count > at /usr/share/shorewall/Shorewall/Chains.pm line 814Steven, I believe that the attached patch corrects both problems. It will apply with offsets. -Tom PS -- I think this is an existing issue not related to 4.4.20. -- 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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 5/23/11 4:37 PM, Mr Dash Four wrote:>> > This is hilarious this is!Glad to hear you are laughing.> > OK, this is what I''ve done: > > 1. I''ve copied /usr/share/shorewall/action.Drop and > /usr/share/shorewall/action.Reject to /etc/shorewall as they were the > only two action.* files in that directory (I left actions.std in > /usr/share/shorewall)Okay.> 2. mv /etc/shorewall/action.Drop /etc/shorewall/action.ADrop && mv > /etc/shorewall/action.Reject /etc/shorewall/action.AReject > 3. Edited shorewall.conf to change DROP_DEFAULT="ADrop" and > REJECT_DEFAULT="AReject" (/etc/shorewall is in my CONFIG_PATH) > 4. "shorewall check" gives me "ERROR: Default Action DROP_DEFAULT=ADrop > not found"You need to add it to your /etc/shorewall/actions file.> 5. I then figured shorewall must be treating ADrop as a "user-defined" > action which needs to be listed in actions. So, I added "ADrop # > replaces the default Drop action" and "AReject # replaces the default > Reject action" to /etc/shorewall/actions > 6. Ran "shorewall check" again and got this "ERROR: Internal error in > Shorewall::Chains::new_chain at /usr/share/shorewall/Shorewall/Chains.pm > line 1200"The patch that I posted in response Steven Springl''s report may fix this.> > Now, I am still completely in the dark where the definitions of all the > allowBcast, allowInvalid, allowinUPnP, allowoutUPnP, dropBcast, > dropInvalid, dropNotSyn, forwardUPnP and rejNotSyn are so that I could > add the "audit" option allowing auditing.In /etc/shorewall/A*, replace allowBcast with allowBcast(reject), etc.> > My ultimate goal also is to be able to control all the auto-generated > chains with the names of the above actions so that I could audit those - > I take it after redefining the above actions this is what would happen.Well, if you really want to audit every broadcast that your firewall receives, then go for it. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 5/23/11 5:28 PM, Mr Dash Four wrote:> >> 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 >> > I''ve just tested this (with the exception of MACLIST_DISPOSITION), > though I do not know why I can''t disable the logging (to the syslog) as > the tcpflags chain is as follows: > > Chain logflags (5 references) > pkts bytes target prot opt in out source > destination > 0 0 LOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 LOG flags 4 level 6 prefix `Shorewall:logflags:A_DROP:'' > 0 0 AUDIT all -- * * 0.0.0.0/0 > 0.0.0.0/0 AUDIT drop > 0 0 DROP all -- * * 0.0.0.0/0 > 0.0.0.0/0 > > Is there a way I could get rid of the first statement?''man shorewall.conf'' and look for TCP_FLAGS_LOG_LEVEL> >> 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. >> > Two things: > > Chain smurfs (2 references) > pkts bytes target prot opt in out source > destination > 0 0 RETURN all -- * * 0.0.0.0 > 0.0.0.0/0 > 0 0 smurflog all -- * * 0.0.0.0/0 > 0.0.0.0/0 [goto] ADDRTYPE match src-type BROADCAST > 0 0 smurflog all -- * * 224.0.0.0/4 > 0.0.0.0/0 [goto] > > I can''t see a way in which there will ever be a jump to smurflog!Look at the first rule again. Apparently, there is an optional interface that is not currently up so Shorewall uses an unmatchable address (0.0.0.0) in that case. What is causing this? Also, the same comment as with logflags above:> > Chain smurflog (2 references) > pkts bytes target prot opt in out source > destination > 0 0 LOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:smurfs:DROP:'' > 0 0 AUDIT all -- * * 0.0.0.0/0 > 0.0.0.0/0 AUDIT drop > 0 0 DROP all -- * * 0.0.0.0/0 > 0.0.0.0/0 > > Is there a way to get rid of the LOG statement?man shorewall.conf and look for SMURF_LOG_LEVEL> >> f) An ''audit'' option has been added to the >> /etc/shorewall/blacklist file which causes the packets matching >> the entryto be audited. ''audit'' may not be specified together >> with ''accept''. >> > That works beautifully!Good. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> The patch that I posted in response Steven Springl''s report may fix this. >Yeah, it did. After further testing I found this: AllowICMPs(audit) does not produce any audit jumps, but still uses ACCEPT statements. Similarly, DropUPnP(audit) just DROPs instead of A_DROP. Same goes for DropDNS(audit) - DROP is the iptables statement instead of A_DROP.> Well, if you really want to audit every broadcast that your firewall > receives, then go for it. >That''s not the point - I am testing functionality, hence check for all possible remotely-sane scenarios provided I have adhered to the correct shorewall syntax. ------------------------------------------------------------------------------ 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
On 5/23/11 6:07 PM, Mr Dash Four wrote:> >> The patch that I posted in response Steven Springl''s report may fix this. >> > Yeah, it did. After further testing I found this: > > AllowICMPs(audit) does not produce any audit jumps, but still uses > ACCEPT statements. Similarly, DropUPnP(audit) just DROPs instead of > A_DROP. Same goes for DropDNS(audit) - DROP is the iptables statement > instead of A_DROP.I didn''t expect A_DROPs -- look at the generated rules again. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> ''man shorewall.conf'' and look for TCP_FLAGS_LOG_LEVEL > > [...] > Look at the first rule again. Apparently, there is an optional interface > that is not currently up so Shorewall uses an unmatchable address > (0.0.0.0) in that case. > > [...] > > man shorewall.conf and look for SMURF_LOG_LEVEL >That did it - all of the smurflogs and tcplogs chains are gone now - as they should. As for this interface which isn''t running - it is my tun0 device, though I have a reference (i.e. a jump) to the smurfs chain from net2fw (it follows immediately after blacklst), so I am not sure that''s right. I have also discovered this little gem: Chain AReject (0 references) pkts bytes target prot opt in out source destination 0 0 all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 A_REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 /* Auth */ I am not at all clear how the first statement will be executed! ------------------------------------------------------------------------------ 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
>> Yeah, it did. After further testing I found this: >> >> AllowICMPs(audit) does not produce any audit jumps, but still uses >> ACCEPT statements. Similarly, DropUPnP(audit) just DROPs instead of >> A_DROP. Same goes for DropDNS(audit) - DROP is the iptables statement >> instead of A_DROP. >> > > I didn''t expect A_DROPs -- look at the generated rules again. >Do I look at the generated .start or somewhere else? ------------------------------------------------------------------------------ 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
On 5/23/11 6:21 PM, Mr Dash Four wrote:> >> ''man shorewall.conf'' and look for TCP_FLAGS_LOG_LEVEL >> >> [...] >> Look at the first rule again. Apparently, there is an optional interface >> that is not currently up so Shorewall uses an unmatchable address >> (0.0.0.0) in that case. >> >> [...] >> >> man shorewall.conf and look for SMURF_LOG_LEVEL >> > That did it - all of the smurflogs and tcplogs chains are gone now - as > they should. As for this interface which isn''t running - it is my tun0 > device, though I have a reference (i.e. a jump) to the smurfs chain from > net2fw (it follows immediately after blacklst), so I am not sure that''s > right. > > I have also discovered this little gem: > > Chain AReject (0 references) > pkts bytes target prot opt in out source > destination > 0 0 all -- * * 0.0.0.0/0 0.0.0.0/0 > 0 0 A_REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 /* Auth */AReject is yours, not mine. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 5/23/11 6:24 PM, Mr Dash Four wrote:> >>> Yeah, it did. After further testing I found this: >>> >>> AllowICMPs(audit) does not produce any audit jumps, but still uses >>> ACCEPT statements. Similarly, DropUPnP(audit) just DROPs instead of >>> A_DROP. Same goes for DropDNS(audit) - DROP is the iptables statement >>> instead of A_DROP. >>> >> >> I didn''t expect A_DROPs -- look at the generated rules again. >> > Do I look at the generated .start or somewhere else?Or start the thing and look at ''shorewall show''. You need to follow the rules to where your modified actions are invoked and then see what they invoke. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 5/23/11 6:34 PM, Tom Eastep wrote:> On 5/23/11 6:24 PM, Mr Dash Four wrote: >> >>>> Yeah, it did. After further testing I found this: >>>> >>>> AllowICMPs(audit) does not produce any audit jumps, but still uses >>>> ACCEPT statements. Similarly, DropUPnP(audit) just DROPs instead of >>>> A_DROP. Same goes for DropDNS(audit) - DROP is the iptables statement >>>> instead of A_DROP. >>>> >>> >>> I didn''t expect A_DROPs -- look at the generated rules again. >>> >> Do I look at the generated .start or somewhere else? > > Or start the thing and look at ''shorewall show''. You need to follow the > rules to where your modified actions are invoked and then see what they > invoke.I did a simple test. a) cp /usr/share/shorewall/action.Drop /etc/shorewall/ b) Changed ''dropBcast'' to ''dropBcast(audit)'' in /etc/shorewall/action.Drop c) shorewall restart Shorewall show includes: oot@gateway:/etc/shorewall# shorewall show Drop Shorewall 4.4.20-Beta3 Chain Drop at gateway - Mon May 23 18:44:06 PDT 2011 Counters reset Mon May 23 18:41:19 PDT 2011 Chain Drop (6 references) pkts bytes target prot opt in out source destination 2 96 all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 reject tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 /* Auth */ 2 96 %dropBcast all -- * * 0.0.0.0/0 0.0.0.0/0 ---------- and this oot@gateway:/etc/shorewall# shorewall show %dropBcast Shorewall 4.4.20-Beta3 Chain %dropBcast at gateway - Mon May 23 18:44:55 PDT 2011 Counters reset Mon May 23 18:41:19 PDT 2011 Chain %dropBcast (1 references) pkts bytes target prot opt in out source destination 0 0 A_DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST 0 0 A_DROP all -- * * 0.0.0.0/0 224.0.0.0/4 root@gateway:/etc/shorewall# -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 \________________________________________________ ------------------------------------------------------------------------------ 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
>>> I didn''t expect A_DROPs -- look at the generated rules again. >>> >>> >> Do I look at the generated .start or somewhere else? >> > > Or start the thing and look at ''shorewall show''. You need to follow the > rules to where your modified actions are invoked and then see what they > invoke. >"shorewall show" outputs this: Chain ADrop (4 references) pkts bytes target prot opt in out source destination 0 0 all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 A_REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 /* Auth */ 0 0 %dropBcast all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 4 /* Needed ICMP types */ 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11 /* Needed ICMP types */ 0 0 %dropInvalid all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 A_DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,445 /* SMB */ 0 0 A_DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:139 /* SMB */ 0 0 A_DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:137 dpts:1024:65535 /* SMB */ 0 0 A_DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,139,445 /* SMB */ 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1900 /* UPnP */ 0 0 %dropNotSyn tcp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 /* Late DNS Replies */ Chain AReject (0 references) pkts bytes target prot opt in out source destination 0 0 all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 A_REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 /* Auth */ 0 0 %dropBcast all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3 code 4 /* Needed ICMP types */ 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11 /* Needed ICMP types */ 0 0 %dropInvalid all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 A_REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,445 /* SMB */ 0 0 A_REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:137:139 /* SMB */ 0 0 A_REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:137 dpts:1024:65535 /* SMB */ 0 0 A_REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 135,139,445 /* SMB */ 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1900 /* UPnP */ 0 0 %dropNotSyn tcp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 /* Late DNS Replies */ Notice the ACCEPT and DROP jumps in both chains. I have this in my action.AReject and action.ADrop respectively: AllowICMPs(audit) - - icmp DropUPnP(audit) DropDNSrep(audit) So, shouldn''t the above be A_ACCEPT and A_DROP instead of ACCEPT and DROP then? ------------------------------------------------------------------------------ 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
>> I have also discovered this little gem: >> >> Chain AReject (0 references) >> pkts bytes target prot opt in out source >> destination >> 0 0 all -- * * 0.0.0.0/0 0.0.0.0/0 >> 0 0 A_REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 /* Auth */ >> > > AReject is yours, not mine. >Bugger! I figured it out - it is "COUNT", which just counts the packets traversing through I presume (hence the absence of a target jump). ------------------------------------------------------------------------------ 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
> I did a simple test. >The problem is not with dropBroadcast - the problem is with AllowICMPs(audit), DropUPnP(audit) and DropDNSrep(audit) respectively - as I already posted. ------------------------------------------------------------------------------ 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
On 5/23/11 6:48 PM, Mr Dash Four wrote:> >>>> I didn''t expect A_DROPs -- look at the generated rules again. >>>> >>>> >>> Do I look at the generated .start or somewhere else? >>> >> >> Or start the thing and look at ''shorewall show''. You need to follow the >> rules to where your modified actions are invoked and then see what they >> invoke. >> > "shorewall show" outputs this: > > Chain ADrop (4 references) > pkts bytes target prot opt in out source > destination > 0 0 all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 A_REJECT tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 tcp dpt:113 /* Auth */ > 0 0 %dropBcast all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT icmp -- * * 0.0.0.0/0 > 0.0.0.0/0 icmp type 3 code 4 /* Needed ICMP types */ > 0 0 ACCEPT icmp -- * * 0.0.0.0/0 > 0.0.0.0/0 icmp type 11 /* Needed ICMP types */ > 0 0 %dropInvalid all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 A_DROP udp -- * * 0.0.0.0/0 > 0.0.0.0/0 multiport dports 135,445 /* SMB */ > 0 0 A_DROP udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp dpts:137:139 /* SMB */ > 0 0 A_DROP udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp spt:137 dpts:1024:65535 /* SMB */ > 0 0 A_DROP tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 multiport dports 135,139,445 /* SMB */ > 0 0 DROP udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp dpt:1900 /* UPnP */ > 0 0 %dropNotSyn tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 DROP udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp spt:53 /* Late DNS Replies */ > > Chain AReject (0 references) > pkts bytes target prot opt in out source > destination > 0 0 all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 A_REJECT tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 tcp dpt:113 /* Auth */ > 0 0 %dropBcast all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT icmp -- * * 0.0.0.0/0 > 0.0.0.0/0 icmp type 3 code 4 /* Needed ICMP types */ > 0 0 ACCEPT icmp -- * * 0.0.0.0/0 > 0.0.0.0/0 icmp type 11 /* Needed ICMP types */ > 0 0 %dropInvalid all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 A_REJECT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 multiport dports 135,445 /* SMB */ > 0 0 A_REJECT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp dpts:137:139 /* SMB */ > 0 0 A_REJECT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp spt:137 dpts:1024:65535 /* SMB */ > 0 0 A_REJECT tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 multiport dports 135,139,445 /* SMB */ > 0 0 DROP udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp dpt:1900 /* UPnP */ > 0 0 %dropNotSyn tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 DROP udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp spt:53 /* Late DNS Replies */ > > Notice the ACCEPT and DROP jumps in both chains. I have this in my > action.AReject and action.ADrop respectively: > > AllowICMPs(audit) - - icmp > DropUPnP(audit) > DropDNSrep(audit) > > So, shouldn''t the above be A_ACCEPT and A_DROP instead of ACCEPT and > DROP then?No -- not unless you have modified the macros like I suggested in an earlier post. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
>> AllowICMPs(audit) - - icmp >> DropUPnP(audit) >> DropDNSrep(audit) >> >> So, shouldn''t the above be A_ACCEPT and A_DROP instead of ACCEPT and >> DROP then? >> > > No -- not unless you have modified the macros like I suggested in an > earlier post. >So, in other words, specifying "audit" in the above 3 macros is completely meaningless then? ------------------------------------------------------------------------------ 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
> Look at the first rule again. Apparently, there is an optional interface > that is not currently up so Shorewall uses an unmatchable address > (0.0.0.0) in that case. >I have also looked at one of my other machines (running 19.3 though) and in there I see exactly the same situation: Chain smurfs (6 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- * * 0.0.0.0 0.0.0.0/0 0 0 smurflog all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] ADDRTYPE match src-type BROADCAST 0 0 smurflog all -- * * 224.0.0.0/4 0.0.0.0/0 [goto] That system has 4 interfaces and they are all UP and RUNNING. To me, the 2nd and last statements will never execute - at all! ------------------------------------------------------------------------------ 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
> Thank you for testing, >One other thing I''ve just discovered by looking in the /usr/share/shorewall directory - in modules.essential you load nf_connttrack without parameters which usually produces a healthy moan that the bloody "CONFIG_NF_CT_ACCT is deprecated and will be removed soon." - I always wondered where the hell is that coming from when I look at the startup logs and finally found out! You need to add "acct=1" as a parameter when you load that module to prevent this message. ------------------------------------------------------------------------------ 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
On 5/23/11 6:54 PM, Mr Dash Four wrote:> >>> AllowICMPs(audit) - - icmp >>> DropUPnP(audit) >>> DropDNSrep(audit) >>> >>> So, shouldn''t the above be A_ACCEPT and A_DROP instead of ACCEPT and >>> DROP then? >>> >> >> No -- not unless you have modified the macros like I suggested in an >> earlier post. >> > So, in other words, specifying "audit" in the above 3 macros is > completely meaningless then?You are an output-only device which I''m now shutting off for the night. Good evening, -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 \________________________________________________ ------------------------------------------------------------------------------ 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
>>>> AllowICMPs(audit) - - icmp >>>> DropUPnP(audit) >>>> DropDNSrep(audit) >>>> >>>> So, shouldn''t the above be A_ACCEPT and A_DROP instead of ACCEPT and >>>> DROP then? >>>> >>>> >>> No -- not unless you have modified the macros like I suggested in an >>> earlier post. >>> >>> >> So, in other words, specifying "audit" in the above 3 macros is >> completely meaningless then? >> > > You are an output-only device which I''m now shutting off for the night. >Yeah, as if! If I understood you correctly, your earlier "suggestion" was this:> I would > > [...] > - Modify the copy as needed. You might also need to copy macros like macro.SMB that are invoked by the action if you want audited copies of those as well >So, in order to make a default action fully accept "audit" (something you claim is now "supported" in .20-Beta3) I have to 1) find out what macros these default actions depend on; 2) decide (by means of testing) which of those macros support "audit" and which do not; 3) copy, then edit, then change those macros that do not support "audit"; 4) edit my actions file to reflect these changes I have just made and finally 5) change my shorewall.conf to add these newly-defined "custom actions" in? Right! Do you think I have the word "Goofy" imprinted on my forehead by any chance? ------------------------------------------------------------------------------ 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
On 24 May 2011 12:43, Mr Dash Four <mr.dash.four@googlemail.com> wrote:> Yeah, as if! > > If I understood you correctly, your earlier "suggestion" was this: > >> I would >> >> [...] >> - Modify the copy as needed. You might also need to copy macros like macro.SMB that are invoked by the action if you want audited copies of those as well >> > So, in order to make a default action fully accept "audit" (something > you claim is now "supported" in .20-Beta3) I have to 1) find out what > macros these default actions depend on; 2) decide (by means of testing) > which of those macros support "audit" and which do not; 3) copy, then > edit, then change those macros that do not support "audit"; 4) edit my > actions file to reflect these changes I have just made and finally 5) > change my shorewall.conf to add these newly-defined "custom actions" in? > > Right! Do you think I have the word "Goofy" imprinted on my forehead by > any chance?Do you find that taking this repugnant attitude when asking for help generally works for you? Tom has carefully responded to your questions. I suggest you show some respect, civility and gratitude. Shorewall is a product worked on entirely voluntarily by Tom, and he has no obligation what so ever to supporting you, but nonetheless has expended time in energy trying to do so. Your response is unwarranted. Try to be more constructive in future. ------------------------------------------------------------------------------ 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
On 05/24/2011 04:43 AM, Mr Dash Four wrote:> >>>>> AllowICMPs(audit) - - icmp >>>>> DropUPnP(audit) >>>>> DropDNSrep(audit) >>>>> >>>>> So, shouldn''t the above be A_ACCEPT and A_DROP instead of ACCEPT and >>>>> DROP then? >>>>> >>>>> >>>> No -- not unless you have modified the macros like I suggested in an >>>> earlier post. >>>> >>>> >>> So, in other words, specifying "audit" in the above 3 macros is >>> completely meaningless then? >>> >> >> You are an output-only device which I''m now shutting off for the night. >> > Yeah, as if! > > If I understood you correctly, your earlier "suggestion" was this: > >> I would >> >> [...] >> - Modify the copy as needed. You might also need to copy macros like macro.SMB that are invoked by the action if you want audited copies of those as well >> > So, in order to make a default action fully accept "audit" (something > you claim is now "supported" in .20-Beta3) I have to 1) find out what > macros these default actions depend on; 2) decide (by means of testing) > which of those macros support "audit" and which do not; 3) copy, then > edit, then change those macros that do not support "audit"; 4) edit my > actions file to reflect these changes I have just made and finally 5) > change my shorewall.conf to add these newly-defined "custom actions" in? > > Right! Do you think I have the word "Goofy" imprinted on my forehead by > any chance?I was (foolishly) hoping that you would create and contribute audited versions of the standard default actions (and learn something about Shorewall in the process) but I see that was a pipe dream. So I spent 11 minutes and created them myself. Hopefully you will be able to integrate these into your configuration. If not, you can wait until Beta 4 when they will be included in the standard product. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 05/24/2011 07:06 AM, Tom Eastep wrote:> On 05/24/2011 04:43 AM, Mr Dash Four wrote:> So I spent 11 minutes and created them myself.Guess I should have spent 12 minutes -- corrected action.ADrop attached. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> I was (foolishly) hoping that you would create and contribute audited > versions of the standard default actions (and learn something about > Shorewall in the process) but I see that was a pipe dream. So I spent 11 > minutes and created them myself. > > Hopefully you will be able to integrate these into your configuration. > If not, you can wait until Beta 4 when they will be included in the > standard product. >That wasn''t my point! I know how to change these in order to allow the new audit feature to function properly (it would take me less than 12 minutes to do so - even with the fairly crappy perl "skills" I possess) - my point is that if shorewall is going to support the audit feature - out-of-the-box so to speak - the end user (i.e. me) shouldn''t have to mess about with actions and macros and so forth in order to enable a feature, which is supposed to be "supported" in shorewall in the first place! ------------------------------------------------------------------------------ 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
>> So I spent 11 minutes and created them myself. >> > > Guess I should have spent 12 minutes -- corrected action.ADrop attached. >You may rename ADrop/AReject to A_Drop/A_Reject to make it consistent with the rest of the audit actions/targets. ------------------------------------------------------------------------------ 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
> You may rename ADrop/AReject to A_Drop/A_Reject to make it consistent > with the rest of the audit actions/targets.It would be even better if I could use "Drop(audit)" and "Reject(audit)" instead without the need to clutter the shorewall directory with macros/actions which only differ by a single element (DROP/A_DROP etc). Don''t know how doable would that be though. ------------------------------------------------------------------------------ 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
On 05/24/2011 08:37 AM, Mr Dash Four wrote:> >> You may rename ADrop/AReject to A_Drop/A_Reject to make it consistent >> with the rest of the audit actions/targets. > It would be even better if I could use "Drop(audit)" and "Reject(audit)" > instead without the need to clutter the shorewall directory with > macros/actions which only differ by a single element (DROP/A_DROP etc). > Don''t know how doable would that be though.Not very doable -- I considered and rejected that approach. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 05/24/2011 08:25 AM, Mr Dash Four wrote:> >> I was (foolishly) hoping that you would create and contribute audited >> versions of the standard default actions (and learn something about >> Shorewall in the process) but I see that was a pipe dream. So I spent 11 >> minutes and created them myself. >> >> Hopefully you will be able to integrate these into your configuration. >> If not, you can wait until Beta 4 when they will be included in the >> standard product. >> > That wasn''t my point! > > I know how to change these in order to allow the new audit feature to > function properly (it would take me less than 12 minutes to do so - even > with the fairly crappy perl "skills" I possess)Did you see any Perl in the files I sent -- I didn''t. - my point is that if> shorewall is going to support the audit feature - out-of-the-box so > to speak - the end user (i.e. me) shouldn''t have to mess about with > actions and macros and so forth in order to enable a feature, which > is supposed to be "supported" in shorewall in the first place!No -- but I think that only a very small percentage of users will want to audit at the level that ADrop and AReject do (I definitely don''t). So the majority of users are either going to have to start with the unaudited versions and add the auditing that they want or they are going to have to start with the audited versions are remove the auditing that they don''t want. In either case, a user is going to have to understand Shorewall actions and macros enough to make the needed modifications. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On Tuesday 24 May 2011 01:41:47 Tom Eastep wrote:> On 5/23/11 4:12 PM, Steven Jan Springl wrote: > > The attached config. produces the following error message: > > > > ERROR: Internal error in Shorewall::Chains::new_chain > > at /usr/share/shorewall/Shorewall/Chains.pm line 1200 > > > > ------------------------------------------------------------------------- > >---------------------- > > > > In the attached config action.sjs contains 2 PERMIT statements. > > If the first is commented out and the second uncommented the following > > error messages are produced: > > > > Use of uninitialized value in numeric gt (>) > > at /usr/share/shorewall/Shorewall/Chains.pm line 814. > > > > ERROR: Internal error in Shorewall::Chains::decrement_reference_count > > at /usr/share/shorewall/Shorewall/Chains.pm line 814 > > Steven, > > I believe that the attached patch corrects both problems. It will apply > with offsets. > > -Tom > > PS -- I think this is an existing issue not related to 4.4.20.Tom I can confirm the patch corrects both problems. My ''swiss army knife config.'' identified the first problem. This did not occur with 4.4.19 or 4.4.20-Beta1. I don''t know about the second problem, that only came to light whilst trying to track down the source of the first problem. Steven. ------------------------------------------------------------------------------ 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
On 5/24/11 8:54 AM, Steven Jan Springl wrote:> > I can confirm the patch corrects both problems. > > My ''swiss army knife config.'' identified the first problem. This did not occur > with 4.4.19 or 4.4.20-Beta1. I don''t know about the second problem, that only > came to light whilst trying to track down the source of the first problem.Thanks, Steven Both problems were introduced in Beta 3. -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 \________________________________________________ ------------------------------------------------------------------------------ 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