All of these are for v4.5.9 and (possibly) above:
1. Upon execution of "shorewall compile [file]" the following leftover
exist in the RAW table:
Chain fooXNNNNNN (0 references)
pkts bytes target prot opt in out source
destination
0 0 CT all -- * * 0.0.0.0/0
0.0.0.0/0 CT notrack
0 0 CT all -- * * 0.0.0.0/0
0.0.0.0/0 CT notrack
If I execute "shorewall compile [file]" 20 times, I will have 20
different chains called "fooXNNNNN" in my raw table.
2. "-r" and "-T" shorewall update options are not
documented.
3. Upon startup, I get the following group of messages:
shorewall[889]: Priority of the eth0 tcp-ack filter is 266
shorewall[889]: Priority of the <all other net devices defined and
used in tcclasses> tcp-ack filter is 266
in tcclasses I have the following, which, to my understanding, is
correct (e:10 refers to eth0, class number 10):
e:10 - 10*full/100 full 1 tcp-ack
I have similar arrangement for all other interfaces. So, why is the
allocated priority 266 instead of what I specified (1)?
4. NFLOG ACTION statement not recognised by shorewall.
According to "man shorewall-rules", I can include NFLOG in the ACTION
column (in a similar fashion as I specify "ACCEPT", "DROP",
"LOG" etc).
This ain''t so:
/etc/shorewall/rules
~~~~~~~~~~~~~~~~~~~~
NFLOG(1,0,1)
gives me "ERROR: Unknown ACTION (NFLOG(1,0,1))". I suffer a similar
faith if I wish to include the same statement as part of action or a
macro. Why?
5. LOG action seems to be ignored when used in a user-defined action:
/etc/shorewall/actions
~~~~~~~~~~~~~~~~~~~~~~
C_ACTION # whatever
/etc/shorewall/action.C_ACTION
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LOG
/etc/shorewall/policy
~~~~~~~~~~~~~~~~~~~~~
$FW net DROP:C_ACTION info
produces this:
*filter
[...]
:C_ACTION - [0:0]
[...]
-A fw2net -j C_ACTION
-A fw2net -j LOG --log-level 6 --log-prefix "Shorewall:fw2net:DROP:"
-A fw2net -j DROP
C_ACTION is empty, but it is supposed to contain a single LOG jump or
give me an error if such log level is not specified. Same goes if I have
this in my rules file:
C_ACTION $FW net
The above two bugs make it impossible to define a separate (custom)
action or a macro, incorporating logging of a packet to multiple
(different) destinations/targets - either via the standard LOG target or
via NFLOG classes, let alone define a suitable policy incorporating that
action (or a macro - see next 2 bugs below).
Two use cases:
a) If I wish to have a "custom" action utilising 3 different LOG
destinations before dropping a packet (say, one local via the standard
LOG target, one remote using NFLOG class 1 and another NFLOG target for
class 2) this cannot be achieved, e.g. something like:
/etc/shorewall/action.C_ACTION
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LOG:<log_level> # using the log-level specified as parameter to the action
NFLOG(1,0,1)
NFLOG(2,0,1)
DROP
and then utilising it in rules as:
C_ACTION:<log_level>
won''t work.
b) If I wish to define a "default" policy for, say, $FW->net
connections
to utilise a custom action logging a packet to 3 different destinations
(as in the case I described above) before dropping a packet, like:
/etc/shorewall/action.C_ACTION
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LOG:<log_level> # using the log-level specified as parameter to the action
NFLOG(1,0,1)
NFLOG(2,0,1)
and then
/etc/shorewall/policy
~~~~~~~~~~~~~~~~~~~~~
$FW net DROP:C_ACTION <log_level>
that won''t work also.
6. USE_ACTIONS shorewall.conf option is not documented/present - even
though it is mentioned as part of
[ACCEPT|DROP|REJECT|NFQUEUE|QUEUE]_DEFAULT option help, there is no
separate help text describing its function/purpose. It is not included
as part of the default shorewall.conf either (if it is indeed intended
for use in shorewall.conf).
7. In "man shorewall-policy" the syntax is described as
"{ACCEPT|DROP|REJECT|CONTINUE|QUEUE|NFQUEUE[(queuenumber)]|NONE}[:{default-action-or-macro|None}]"
where "default-action-or-macro" is the name of an action (if
USE_ACTIONS=Yes - see previous bug above) or a macro (if
USE_ACTIONS=No/Not specified?). That doesn''t work for macros.
/etc/shorewall/macro.C_MACRO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LOG
PARAM
/etc/shorewall/policy
~~~~~~~~~~~~~~~~~~~~~
$FW net DROP:C_MACRO info
gets me "ERROR: Unknown Default Action (C_MACRO)" message. Why?
Finally, two feature requests:
1. Add X:UN|X:U (or similar) option in "secmarks" to support the
UNTRACKED state ("X" is the base chain - INPUT, OUTPUT, FORWARD).
Example:
secmarks
~~~~~~~~
system_u:object_r:whatever_t:s0 I:UN
to be the equivalent of:
iptables -t mangle -A INPUT -m conntrack --ctstate NEW,UNTRACKED -j
SECMARK --selctx system_u:object_r:whatever_t:s0
2. Add the ability to include rules in the raw table.
Use case: When I am allocated a (dynamic) IP address from my (external)
DHCP provider, I am usually a part of a (rather large) subnet containing
many other users. A while back I started getting a lot of attacks based
on carefully-crafted packets originating from that (large) subnet and
destined to my machine.
Since by definition there is a pre-defined route added to encompass the
entire subnet when my device is allocated an IP address, this allows a
lot of machines on the subnet an easy access to my own - "by default",
so to speak. To counter that, I black-holed the route to all IP
addresses from that subnet and left out only my own
(dynamically-allocated) IP address and the gateway address.
That solved the problem, but brought another one - logging martians as,
naturally, when a crafted packet arrives on my interface from one of the
black-holed IP addresses, or worse, originates from my own interface and
is destined to one of those IP addresses, it gets marked as a martian as
there is no route to it and I get it logged.
I finally solved that problem by including a (manual) set of rules in my
raw table which dumps (understand DROPs) these addresses even before a
routing decision is made. Since the raw table has, to my knowledge, the
highest priority, I could include rules there which supersede routing or
connection tracking decisions. In other words, I could have a set of
rules processed before any connection tracking or routing decision is
made, which is very handy!
Currently I do this in "init" and "started", but it would be
nice if I
do not hack it like that and am able to add such rules more
"naturally".
I am aware that I could easily block the entire subnet, bar my own and
the gateway IP addresses via "regular" rules in "rules", but
I wish to
include these *before* any routing or connection-tracking decisions are
made. I am also aware that there is possible performance penalty from
this as these rules are processed for *every* packet, but I am willing
to take that hit.
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/18/2012 09:16 AM, Mr Dash Four wrote:> All of these are for v4.5.9 and (possibly) above: > > 1. Upon execution of "shorewall compile [file]" the following leftover > exist in the RAW table: > > Chain fooXNNNNNN (0 references) > pkts bytes target prot opt in out source > destination > 0 0 CT all -- * * 0.0.0.0/0 > 0.0.0.0/0 CT notrack > 0 0 CT all -- * * 0.0.0.0/0 > 0.0.0.0/0 CT notrack > > If I execute "shorewall compile [file]" 20 times, I will have 20 > different chains called "fooXNNNNN" in my raw table.I''m unable to reproduce that problem. root@gateway:~# shorewall -qqq compile foobaroo Compiling... root@gateway:~# shorewall show raw Shorewall 4.5.9.2 RAW Table at gateway - Sun Nov 18 10:05:26 PST 2012 Counters reset Sun Nov 18 09:54:28 PST 2012 Chain PREROUTING (policy ACCEPT 197 packets, 78273 bytes) pkts bytes target prot opt in out source destination 3846 356K loc_ctrk all -- eth2 * 172.20.1.0/24 0.0.0.0/0 0 0 RETURN all -- eth1 * 10.1.10.0/24 0.0.0.0/0 0 0 RETURN all -- eth1 * 0.0.0.0/0 0.0.0.0/0 match-set subnet src 0 0 RETURN all -- eth0 * 0.0.0.0/0 0.0.0.0/0 match-set subnet src 77 7700 NOTRACK all -- eth1 * 192.88.99.1 0.0.0.0/0 0 0 NOTRACK all -- eth0 * 192.88.99.1 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 42 packets, 4344 bytes) pkts bytes target prot opt in out source destination 0 0 NOTRACK udp -- * * 0.0.0.0/0 255.255.255.255 2 476 NOTRACK udp -- * * 0.0.0.0/0 172.20.1.255 0 0 NOTRACK udp -- * * 0.0.0.0/0 70.90.191.127 131 13100 NOTRACK all -- * * 0.0.0.0/0 192.88.99.1 Chain loc_ctrk (1 references) pkts bytes target prot opt in out source destination 95 8528 NOTRACK udp -- * * 0.0.0.0/0 172.20.1.255 2 493 NOTRACK udp -- * * 0.0.0.0/0 255.255.255.255 root@gateway:~#> > 2. "-r" and "-T" shorewall update options are not documented.The last sentence in the ''update'' section of the manpage is: For a description of the other options, see the check command above.> > 3. Upon startup, I get the following group of messages: > > shorewall[889]: Priority of the eth0 tcp-ack filter is 266 > shorewall[889]: Priority of the <all other net devices defined and > used in tcclasses> tcp-ack filter is 266 > > in tcclasses I have the following, which, to my understanding, is > correct (e:10 refers to eth0, class number 10): > e:10 - 10*full/100 full 1 tcp-ack > > I have similar arrangement for all other interfaces. So, why is the > allocated priority 266 instead of what I specified (1)?If you want the tcp-ack filter to have priority 1, specify it as tcp-ack(1)> > 4. NFLOG ACTION statement not recognised by shorewall. > > According to "man shorewall-rules", I can include NFLOG in the ACTION > column (in a similar fashion as I specify "ACCEPT", "DROP", "LOG" etc). > This ain''t so: > > /etc/shorewall/rules > ~~~~~~~~~~~~~~~~~~~~ > NFLOG(1,0,1) > > gives me "ERROR: Unknown ACTION (NFLOG(1,0,1))". I suffer a similar > faith if I wish to include the same statement as part of action or a > macro. Why?That''s an error in the manpage -- to use NFLOG, specify "LOG:NFLOG(1,0,1)".> > 5. LOG action seems to be ignored when used in a user-defined action: > > /etc/shorewall/actions > ~~~~~~~~~~~~~~~~~~~~~~ > C_ACTION # whatever > > /etc/shorewall/action.C_ACTION > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > LOGUse "LOG:<level>!" (note the ''!''). e.g., ''LOG:NFLOG(2,0,1)!''> > /etc/shorewall/policy > ~~~~~~~~~~~~~~~~~~~~~ > $FW net DROP:C_ACTION info > > produces this: > > *filter > [...] > :C_ACTION - [0:0] > [...] > -A fw2net -j C_ACTION > -A fw2net -j LOG --log-level 6 --log-prefix "Shorewall:fw2net:DROP:" > -A fw2net -j DROP > > C_ACTION is empty, but it is supposed to contain a single LOG jump or > give me an error if such log level is not specified. Same goes if I have > this in my rules file: > > C_ACTION $FW net > > The above two bugs make it impossible to define a separate (custom) > action or a macro, incorporating logging of a packet to multiple > (different) destinations/targets - either via the standard LOG target or > via NFLOG classes, let alone define a suitable policy incorporating that > action (or a macro - see next 2 bugs below). > > Two use cases: > > a) If I wish to have a "custom" action utilising 3 different LOG > destinations before dropping a packet (say, one local via the standard > LOG target, one remote using NFLOG class 1 and another NFLOG target for > class 2) this cannot be achieved, e.g. something like: > > /etc/shorewall/action.C_ACTION > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > LOG:<log_level> # using the log-level specified as parameter to the action > NFLOG(1,0,1) > NFLOG(2,0,1) > DROP > > and then utilising it in rules as: > > C_ACTION:<log_level> > > won''t work. > > b) If I wish to define a "default" policy for, say, $FW->net connections > to utilise a custom action logging a packet to 3 different destinations > (as in the case I described above) before dropping a packet, like: > > /etc/shorewall/action.C_ACTION > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > LOG:<log_level> # using the log-level specified as parameter to the action > NFLOG(1,0,1) > NFLOG(2,0,1) > > and then > > /etc/shorewall/policy > ~~~~~~~~~~~~~~~~~~~~~ > $FW net DROP:C_ACTION <log_level>> > that won''t work also. > > 6. USE_ACTIONS shorewall.conf option is not documented/present - even > though it is mentioned as part of > [ACCEPT|DROP|REJECT|NFQUEUE|QUEUE]_DEFAULT option help, there is no > separate help text describing its function/purpose. It is not included > as part of the default shorewall.conf either (if it is indeed intended > for use in shorewall.conf).That option was removed some time ago and is now hard-wired to ''Yes''. I''ll update the manpages as time permits.> > 7. In "man shorewall-policy" the syntax is described as > "{ACCEPT|DROP|REJECT|CONTINUE|QUEUE|NFQUEUE[(queuenumber)]|NONE}[:{default-action-or-macro|None}]" > where "default-action-or-macro" is the name of an action (if > USE_ACTIONS=Yes - see previous bug above) or a macro (if > USE_ACTIONS=No/Not specified?). That doesn''t work for macros. > > /etc/shorewall/macro.C_MACRO > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > LOG > PARAM > > /etc/shorewall/policy > ~~~~~~~~~~~~~~~~~~~~~ > $FW net DROP:C_MACRO info > > gets me "ERROR: Unknown Default Action (C_MACRO)" message. Why?Again, USE_ACTIONS=No is no longer supported. I''ll correct the manpage.> > > Finally, two feature requests: > > 1. Add X:UN|X:U (or similar) option in "secmarks" to support the > UNTRACKED state ("X" is the base chain - INPUT, OUTPUT, FORWARD). Example: > > secmarks > ~~~~~~~~ > system_u:object_r:whatever_t:s0 I:UN > > to be the equivalent of: > > iptables -t mangle -A INPUT -m conntrack --ctstate NEW,UNTRACKED -j > SECMARK --selctx system_u:object_r:whatever_t:s0Patch attached. The new suffixes are: :U (UNTRACKED) :NU (NEW,UNTRACKED) :NIU (NEW,INVALID,UNTRACKED)> > 2. Add the ability to include rules in the raw table. > > Use case: When I am allocated a (dynamic) IP address from my (external) > DHCP provider, I am usually a part of a (rather large) subnet containing > many other users. A while back I started getting a lot of attacks based > on carefully-crafted packets originating from that (large) subnet and > destined to my machine. > > Since by definition there is a pre-defined route added to encompass the > entire subnet when my device is allocated an IP address, this allows a > lot of machines on the subnet an easy access to my own - "by default", > so to speak. To counter that, I black-holed the route to all IP > addresses from that subnet and left out only my own > (dynamically-allocated) IP address and the gateway address. > > That solved the problem, but brought another one - logging martians as, > naturally, when a crafted packet arrives on my interface from one of the > black-holed IP addresses, or worse, originates from my own interface and > is destined to one of those IP addresses, it gets marked as a martian as > there is no route to it and I get it logged. > > I finally solved that problem by including a (manual) set of rules in my > raw table which dumps (understand DROPs) these addresses even before a > routing decision is made. Since the raw table has, to my knowledge, the > highest priority, I could include rules there which supersede routing or > connection tracking decisions. In other words, I could have a set of > rules processed before any connection tracking or routing decision is > made, which is very handy! > > Currently I do this in "init" and "started", but it would be nice if I > do not hack it like that and am able to add such rules more "naturally". > > I am aware that I could easily block the entire subnet, bar my own and > the gateway IP addresses via "regular" rules in "rules", but I wish to > include these *before* any routing or connection-tracking decisions are > made. I am also aware that there is possible performance penalty from > this as these rules are processed for *every* packet, but I am willing > to take that hit.Patch attached. Adds a DROP action to the format-2 conntrack file. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/18/12 11:33 AM, Tom Eastep wrote:>> 4. NFLOG ACTION statement not recognised by shorewall. >> >> According to "man shorewall-rules", I can include NFLOG in the ACTION >> column (in a similar fashion as I specify "ACCEPT", "DROP", "LOG" etc). >> This ain''t so: >> >> /etc/shorewall/rules >> ~~~~~~~~~~~~~~~~~~~~ >> NFLOG(1,0,1) >> >> gives me "ERROR: Unknown ACTION (NFLOG(1,0,1))". I suffer a similar >> faith if I wish to include the same statement as part of action or a >> macro. Why? > > That''s an error in the manpage -- to use NFLOG, specify "LOG:NFLOG(1,0,1)".I decided to change the code rather than the manpage -- patch 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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/18/12 11:33 AM, Tom Eastep wrote:>> >> 3. Upon startup, I get the following group of messages: >> >> shorewall[889]: Priority of the eth0 tcp-ack filter is 266 >> shorewall[889]: Priority of the <all other net devices defined and >> used in tcclasses> tcp-ack filter is 266 >> >> in tcclasses I have the following, which, to my understanding, is >> correct (e:10 refers to eth0, class number 10): >> e:10 - 10*full/100 full 1 tcp-ack >> >> I have similar arrangement for all other interfaces. So, why is the >> allocated priority 266 instead of what I specified (1)? > > If you want the tcp-ack filter to have priority 1, specify it as > tcp-ack(1) >Correction -- make that tcp-ack:1 -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> I''m unable to reproduce that problem. >Test case? If so, what would you like me to include (what is the likely cause of this)?>> 2. "-r" and "-T" shorewall update options are not documented. >> > > The last sentence in the ''update'' section of the manpage is: > > For a description of the other options, see the check command above. >Noted.> If you want the tcp-ack filter to have priority 1, specify it as > tcp-ack(1) >I thought that is what the "priority" column is for, isn''t that the case? From the shorewall-tcclasses man page: PRIORITY - priority [...] For both HTB and HFSC, the priority is used to calculate the priority of following Shorewall-generated classification filters that refer to the class: * Packet MARK * tcp-ack and the tos options (see below) Setting "tcp-ack:1" does indeed suppress that message, though I am intrigued as to why the priority specified in the "priority" column is disregarded?> That''s an error in the manpage -- to use NFLOG, specify "LOG:NFLOG(1,0,1)". >Taking into account your latest response on this - I''ll use "NFLOG(1,0,1)" and see if that does the job.> Use "LOG:<level>!" (note the ''!''). e.g., ''LOG:NFLOG(2,0,1)!'' >Noted, though I have some reservations about using actions - see below.> Again, USE_ACTIONS=No is no longer supported. I''ll correct the manpage. >OK, the way I understand it, I could only use actions in my policy file, right? If so, I am going to have another set of problems: Currently, by its own definition, shorewall macros can "assign" log levels "automatically" to all operators in that macro. For example, if I have the following: macro.C_MACRO ~~~~~~~~~~~~~ LOG NFLOG(1,0,1) NFLOG(2,0,1) DROP and then call it with "C_MACRO:info" in, say, my "rules" file, this will pass this log level (info) "automatically" to LOG (the first operator of C_MACRO) as well as the DROP statement (and create an additional - standard LOG jump) before the packet is dropped. If I use action, how can I achieve this? This is particularly evident in the policy file: When I use "$FW net DROP:C_ACTION info" I would expect the "info" log level to be, somehow, passed to C_ACTION. That doesn''t happen though - all I get is a jump to the C_ACTION chain and then I have an additional LOG in fw2net chain itself - completely detached from C_ACTION. There is additional benefit of using macros as far as I can see: when I use macro, the "code" of that macro is inserted "inline". That has the added benefit of creating the appropriate "labels" and comments for the chain in which this macro originated. In other words, when I use rules ~~~~ C_MACRO:info $FW net This will create 5 inline statements, like so: -A fw2net -j LOG --log-level 6 --log-prefix "Shorewall:fw2net:LOG:" -m comment --comment "C_MACRO" -A fw2net -j NFLOG --nflog-group 1 --nflog-range 0 --nflog-threshold 1 --nflog-prefix "Shorewall:fw2net:LOG:" -m comment --comment "C_MACRO" -A fw2net -j NFLOG --nflog-group 2 --nflog-range 0 --nflog-threshold 1 --nflog-prefix "Shorewall:fw2net:LOG:" -m comment --comment "C_MACRO" -A fw2net -j LOG --log-level 6 --log-prefix "Shorewall:fw2net:DROP:" -m comment --comment "C_MACRO" -A fw2net -j DROP -m comment --comment "C_MACRO" Note the "nflog-prefix", "log-prefix" and "comment" - they are all "tailored" specifically for the chain in which I use that macro - very handy since if I am going to use one macro across the board, the chain from which this call originated could be easily identified ("Shorewall:fw2net:LOG:" and "Shorewall:fw2net:DROP:"). If I use action instead, that won''t be possible since I am going to get this instead: -A C_ACTION -j NFLOG --nflog-group 1 --nflog-range 0 --nflog-threshold 1 --nflog-prefix "Shorewall:C_ACTION:LOG:" -A C_ACTION -j NFLOG --nflog-group 2 --nflog-range 0 --nflog-threshold 1 --nflog-prefix "Shorewall:C_ACTION:LOG:" Notice the nflog-prefix (Shorewall:C_ACTION:LOG:) - there is no way I could identify which chain the packet originated from and there is no comment there either. This might not sound like a big deal, but when I wish to use a single macro in various policy statements for different directions ($FW->net, net->$FW etc), when I get a packet logged, I won''t know which chain this packet originated from, or, at the very least, I have to scratch my head to find out. If I were able to deploy macros in the "policy" instead, this problem goes away as the macro will be included "inline" with the appropriate labels and comments to boot.> Patch attached. The new suffixes are: > > :U (UNTRACKED) > :NU (NEW,UNTRACKED) > :NIU (NEW,INVALID,UNTRACKED) >Noted, I''ll test this later.> Patch attached. Adds a DROP action to the format-2 conntrack file. >Noted, wasn''t aware of the "conntrack" file, but I''ll test this as well - I take it the support for ipsets is there, right? ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/19/12 7:47 AM, Mr Dash Four wrote:> >> I''m unable to reproduce that problem. >> > Test case? If so, what would you like me to include (what is the likely > cause of this)? >The problem is associated with LOAD_HELPERS_ONLY=No; patch attached.>> If you want the tcp-ack filter to have priority 1, specify it as >> tcp-ack(1) >> > I thought that is what the "priority" column is for, isn''t that the > case? From the shorewall-tcclasses man page: > > PRIORITY - priority > [...] > For both HTB and HFSC, the priority is used to calculate the priority of > following Shorewall-generated classification filters that refer to the > class: > * Packet MARK > * tcp-ack and the tos options (see below) > > Setting "tcp-ack:1" does indeed suppress that message, though I am > intrigued as to why the priority specified in the "priority" column is > disregarded?This has been a point of confusion before. The priority displayed in these messages is the *filter* priority. For compatibility with earlier releases, they default to what you are seeing; this is clearly documented in the manpages. Placing the tcp-ack filter at priority 1 means that ACK packets from low-priority bulk traffic will still be treated as high-priority. If that''s what you want, then you need to explicitly specify it.> OK, the way I understand it, I could only use actions in my policy file, > right?Correct. > If so, I am going to have another set of problems:> > Currently, by its own definition, shorewall macros can "assign" log > levels "automatically" to all operators in that macro. For example, if I > have the following: > > macro.C_MACRO > ~~~~~~~~~~~~~ > LOG > NFLOG(1,0,1) > NFLOG(2,0,1) > DROP > > and then call it with "C_MACRO:info" in, say, my "rules" file, this will > pass this log level (info) "automatically" to LOG (the first operator of > C_MACRO) as well as the DROP statement (and create an additional - > standard LOG jump) before the packet is dropped. > > If I use action, how can I achieve this? This is particularly evident in > the policy file: When I use "$FW net DROP:C_ACTION info" I would expect > the "info" log level to be, somehow, passed to C_ACTION. That doesn''t > happen though - all I get is a jump to the C_ACTION chain and then I > have an additional LOG in fw2net chain itself - completely detached from > C_ACTION. > > There is additional benefit of using macros as far as I can see: when I > use macro, the "code" of that macro is inserted "inline". That has the > added benefit of creating the appropriate "labels" and comments for the > chain in which this macro originated. In other words, when I use > > rules > ~~~~ > C_MACRO:info $FW net > > This will create 5 inline statements, like so: > > -A fw2net -j LOG --log-level 6 --log-prefix "Shorewall:fw2net:LOG:" -m > comment --comment "C_MACRO" > -A fw2net -j NFLOG --nflog-group 1 --nflog-range 0 --nflog-threshold 1 > --nflog-prefix "Shorewall:fw2net:LOG:" -m comment --comment "C_MACRO" > -A fw2net -j NFLOG --nflog-group 2 --nflog-range 0 --nflog-threshold 1 > --nflog-prefix "Shorewall:fw2net:LOG:" -m comment --comment "C_MACRO" > -A fw2net -j LOG --log-level 6 --log-prefix "Shorewall:fw2net:DROP:" -m > comment --comment "C_MACRO" > -A fw2net -j DROP -m comment --comment "C_MACRO" > > Note the "nflog-prefix", "log-prefix" and "comment" - they are all > "tailored" specifically for the chain in which I use that macro - very > handy since if I am going to use one macro across the board, the chain > from which this call originated could be easily identified > ("Shorewall:fw2net:LOG:" and "Shorewall:fw2net:DROP:"). If I use action > instead, that won''t be possible since I am going to get this instead: > > -A C_ACTION -j NFLOG --nflog-group 1 --nflog-range 0 --nflog-threshold 1 > --nflog-prefix "Shorewall:C_ACTION:LOG:" > -A C_ACTION -j NFLOG --nflog-group 2 --nflog-range 0 --nflog-threshold 1 > --nflog-prefix "Shorewall:C_ACTION:LOG:" > > Notice the nflog-prefix (Shorewall:C_ACTION:LOG:) - there is no way I > could identify which chain the packet originated from and there is no > comment there either. > > This might not sound like a big deal, but when I wish to use a single > macro in various policy statements for different directions ($FW->net, > net->$FW etc), when I get a packet logged, I won''t know which chain this > packet originated from, or, at the very least, I have to scratch my head > to find out. If I were able to deploy macros in the "policy" instead, > this problem goes away as the macro will be included "inline" with the > appropriate labels and comments to boot.I''ll take a look at this. But in the mean time, you can achieve the same goal by simply placing your logging rules at the end of the rules file with SOURCE and DEST set to ''all''.> > >> Patch attached. The new suffixes are: >> >> :U (UNTRACKED) >> :NU (NEW,UNTRACKED) >> :NIU (NEW,INVALID,UNTRACKED) >> > Noted, I''ll test this later. > >> Patch attached. Adds a DROP action to the format-2 conntrack file. >> > Noted, wasn''t aware of the "conntrack" file, but I''ll test this as well > - I take it the support for ipsets is there, right?Yes. -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 \________________________________________________ -- 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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/19/2012 11:41 AM, Tom Eastep wrote:> On 11/19/12 7:47 AM, Mr Dash Four wrote:>> This might not sound like a big deal, but when I wish to use a single >> macro in various policy statements for different directions ($FW->net, >> net->$FW etc), when I get a packet logged, I won''t know which chain this >> packet originated from, or, at the very least, I have to scratch my head >> to find out. If I were able to deploy macros in the "policy" instead, >> this problem goes away as the macro will be included "inline" with the >> appropriate labels and comments to boot. > > I''ll take a look at this. But in the mean time, you can achieve the same > goal by simply placing your logging rules at the end of the rules file > with SOURCE and DEST set to ''all''.Attached is a lightly-tested patch that allows a macro to be used as a default action. Please try it and provide feedback. Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/19/12 4:25 PM, Tom Eastep wrote:> On 11/19/2012 11:41 AM, Tom Eastep wrote: >> On 11/19/12 7:47 AM, Mr Dash Four wrote: > >>> This might not sound like a big deal, but when I wish to use a single >>> macro in various policy statements for different directions ($FW->net, >>> net->$FW etc), when I get a packet logged, I won''t know which chain this >>> packet originated from, or, at the very least, I have to scratch my head >>> to find out. If I were able to deploy macros in the "policy" instead, >>> this problem goes away as the macro will be included "inline" with the >>> appropriate labels and comments to boot. >> >> I''ll take a look at this. But in the mean time, you can achieve the same >> goal by simply placing your logging rules at the end of the rules file >> with SOURCE and DEST set to ''all''. > > Attached is a lightly-tested patch that allows a macro to be used as a > default action. Please try it and provide feedback.This one is needed also. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
>> I''ll take a look at this. But in the mean time, you can achieve the same >> goal by simply placing your logging rules at the end of the rules file >> with SOURCE and DEST set to ''all''. > > Attached is a lightly-tested patch that allows a macro to be used as a > default action. Please try it and provide feedback.Noted. I take it apart from using that macro in my policy file I don''t have to do anything in addition to that, like specifying USE_ACTIONS and so on, right? I''ll have the chance to test all of your patches tonight and will let you know what''s happening. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/20/2012 07:53 AM, Mr Dash Four wrote:> >>> I''ll take a look at this. But in the mean time, you can achieve the same >>> goal by simply placing your logging rules at the end of the rules file >>> with SOURCE and DEST set to ''all''. >> >> Attached is a lightly-tested patch that allows a macro to be used as a >> default action. Please try it and provide feedback. > Noted. I take it apart from using that macro in my policy file I don''t > have to do anything in addition to that, like specifying USE_ACTIONS and > so on, right? I''ll have the chance to test all of your patches tonight > and will let you know what''s happening.You simply specify the macro name in the POLICY file. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/20/2012 08:15 AM, Tom Eastep wrote:> On 11/20/2012 07:53 AM, Mr Dash Four wrote: >> >>>> I''ll take a look at this. But in the mean time, you can achieve the same >>>> goal by simply placing your logging rules at the end of the rules file >>>> with SOURCE and DEST set to ''all''. >>> >>> Attached is a lightly-tested patch that allows a macro to be used as a >>> default action. Please try it and provide feedback. >> Noted. I take it apart from using that macro in my policy file I don''t >> have to do anything in addition to that, like specifying USE_ACTIONS and >> so on, right? I''ll have the chance to test all of your patches tonight >> and will let you know what''s happening. > > You simply specify the macro name in the POLICY file. >And thanks in advance for helping to test this, -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
>> That''s an error in the manpage -- to use NFLOG, specify "LOG:NFLOG(1,0,1)". > > I decided to change the code rather than the manpage -- patch attached.It doesn''t seem to work: I am getting "ERROR: Invalid NFLOG action(NFLOG(1,0,1):none)" The statement in my C_ACTION is just "NFLOG(1,0,1)" (as oppose to "LOG:NFLOG(1,0,1)"). Am I missing something? ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
>> Test case? If so, what would you like me to include (what is the likely >> cause of this)? >> > > The problem is associated with LOAD_HELPERS_ONLY=No; patch attached.Does the trick - no more leftovers in my raw table. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> Patch attached. The new suffixes are: > > :U (UNTRACKED) > :NU (NEW,UNTRACKED) > :NIU (NEW,INVALID,UNTRACKED)The patch does its job to perfection.> Patch attached. Adds a DROP action to the format-2 conntrack file.That, in general, does not work: I am not sure what I am supposed to put in the SOURCE/DESTINATION columns as a "zone" when in reality I don''t care which "zone" this is in (and I don''t think "all" is appropriate). For example, if I want to emulate "-t raw -I PREROUTING 1 -m set --match-set baddies-set src -j DROP" as well as "-t raw -I OUTPUT 1 -m set --match-set baddies-set dst -j DROP" I tried the following: 1. DROP +baddies-set DROP - +baddies-set Doesn''t work - it is asking me for a zone to put in... 2. DROP $FW:+baddies-set DROP - $FW:+baddies-set Moans about unknown zone ("-")... 3. DROP $FW:+baddies-set DROP all $FW:+baddies-set I am getting "ERROR: Unknown Interface (fw)" error... Further on this - a few suggestions to extend this file''s functionality: 1. I am not sure whether I could use custom action in this file, but it would be very handy if I could. Why? Because if I wish to use such action for creating packet logs to multiple (understand 3) destinations for example, then instead of having 3 separate LOG/NFLOG statements *and* their associate conditionals, I could just have one conditional + custom action, which should, in theory, be translated to a single jump to the corresponding custom-action chain where the multiple packet logs take place. 2. If possible, could you include a SWITCH column (similar to what you already have in "rules") so that this particular rule is switched on/off if/when desired. Finally, a side issue I''ve been having, which up until now was a bit of a mystery to me - until I had a proper look at my (default) conntrack file, that is: every time shorewall starts, I get a group of rather annoying syslog messages like so: xt_CT: No such helper "sane" xt_CT: No such helper "sane-0" xt_CT: No such helper "tftp" xt_CT: No such helper "tftp-0" xt_CT: No such helper "pptp" xt_CT: No such helper "sip" xt_CT: No such helper "sip-0" xt_CT: No such helper "snmp" xt_CT: No such helper "netbios-ns" xt_CT: No such helper "ftp" xt_CT: No such helper "ftp-0" xt_CT: No such helper "irc" xt_CT: No such helper "irc-0" xt_CT: No such helper "amanda" I knew these may have resulted from the fact that I have intentionally disabled (and forcibly removed!) all conntrack kernel helper modules. Until I had a look at the conntrack file, I thought that they were caused by shorewall trying to load the ct kernel helper modules, but after seeing all those conditionals in "conntrack" I am not so sure. Is there any way I could get rid of these messages? Am I doing something wrong? ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> You simply specify the macro name in the POLICY file.Doesn''t seem to work. macro.C_MACRO ~~~~~~~~~~~~~ LOG LOG:NFLOG(1,0,1) LOG:NFLOG(2,0,1) policy ~~~~~~ $FW net DROP:C_MACRO info I am getting "ERROR: LOG requires a log level" policy ~~~~~~ $FW net DROP:C_MACRO:info info This time I am getting "ERROR: Invalid default action (C_MACRO:info)" policy ~~~~~~ $FW net DROP:C_MACRO(info) info This time the message is "ERROR: Default Action Macros may not have parameters" Finally, one question and a suggestion: suppose I would like to conditionally dump packets on both side of a connection initiated from outside. For the incoming part I know I should put the appropriate NFLOG statement in the NEW section. The tricky bit (at least for me anyway) is what to do on the outgoing side, particularly when the connection is already established (I *do* wish to dump every packet regardless of the connection tracking state, including the UNTRACKED ones). Should I then place the appropriate statement in the ALL section of the rules file then? Would that execute prior to the connection tracking state matches (NEW, RELATED, ESTABLISHED)? Do these type of statements (in the ALL section) go after the blackists and the various tcp flag/smurfs and all other checks shorewall has put in place? The suggestion: from what I can gather, currently there isn''t a stand-alone AUDIT statement in the way there are LOG and NFLOG ones. Would it be possible to include one? The type specified in that AUDIT statement (accept, drop and reject) is largely irrelevant as far as iptables go (they do have significance in the audit facility though). The reason I ask this is because if I had this, I could add the AUDIT log target to my custom macro/action when auditing of packets (*without* explicitly dropping/rejecting/accepting them) is needed, along with LOG/NFLOG targets. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> And thanks in advance for helping to test this,Pleasure. I''ll be able to do more testing again when you iron the rough edges - just let me know. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/20/2012 08:18 PM, Mr Dash Four wrote:>>> That''s an error in the manpage -- to use NFLOG, specify >>> "LOG:NFLOG(1,0,1)". >> >> I decided to change the code rather than the manpage -- patch >> attached. > It doesn''t seem to work: I am getting "ERROR: Invalid NFLOG > action(NFLOG(1,0,1):none)" > > The statement in my C_ACTION is just "NFLOG(1,0,1)" (as oppose to > "LOG:NFLOG(1,0,1)"). Am I missing something? > >> You simply specify the macro name in the POLICY file. > Doesn''t seem to work. > > macro.C_MACRO ~~~~~~~~~~~~~ LOG LOG:NFLOG(1,0,1) LOG:NFLOG(2,0,1) > > > policy ~~~~~~ $FW net DROP:C_MACRO info > > I am getting "ERROR: LOG requires a log level" > > policy ~~~~~~ $FW net DROP:C_MACRO:info info > > This time I am getting "ERROR: Invalid default action > (C_MACRO:info)" > > > policy ~~~~~~ $FW net DROP:C_MACRO(info) info > > This time the message is "ERROR: Default Action Macros may not have > parameters"These will have to wait for Beta 2 -- at that point NFLOG() should work as you expect and you can specify ''DROP:C_MACRO(info)'' if you want to make simple ''LOG'' rules log at the ''info'' level.> > Finally, one question and a suggestion: suppose I would like to > conditionally dump packets on both side of a connection initiated > from outside. For the incoming part I know I should put the > appropriate NFLOG statement in the NEW section. The tricky bit (at > least for me anyway) is what to do on the outgoing side, > particularly when the connection is already established (I *do* wish > to dump every packet regardless of the connection tracking state, > including the UNTRACKED ones). > > Should I then place the appropriate statement in the ALL section of > the rules file then? Would that execute prior to the connection > tracking state matches (NEW, RELATED, ESTABLISHED)?Yes> Do these type of statements (in the ALL section) go after the > blackists and the various tcp flag/smurfs and all other checks > shorewall has put in place?Rules in the ALL section come after the blacklist and the interface-option checks. When I want this type of logging, though, I use the ''iptrace'' shorewall command. This not only logs each packet but traces it through the Netfilter chains.> > The suggestion: from what I can gather, currently there isn''t a > stand-alone AUDIT statement in the way there are LOG and NFLOG ones. > Would it be possible to include one? The type specified in that > AUDIT statement (accept, drop and reject) is largely irrelevant as > far as iptables go (they do have significance in the audit facility > though). The reason I ask this is because if I had this, I could add > the AUDIT log target to my custom macro/action when auditing of > packets (*without* explicitly dropping/rejecting/accepting them) is > needed, along with LOG/NFLOG targets.Copy the two attached files into ${SHAREDIR}/shorewall. The new target is ''Audit'' and accepts one optional parameter (the audit type). The default audit type is ''drop''. The action does no logging. Note that iptables requires the ''type'' to be specified. [root@sami ~]# iptables -A foo -j AUDIT iptables v1.4.14: AUDIT: option "--type" must be specified Try `iptables -h'' or ''iptables --help'' for more information. [root@sami ~]# -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/20/2012 08:18 PM, Mr Dash Four wrote:>> Patch attached. The new suffixes are: >> >> :U (UNTRACKED) >> :NU (NEW,UNTRACKED) >> :NIU (NEW,INVALID,UNTRACKED) > The patch does its job to perfection. >Good> >> Patch attached. Adds a DROP action to the format-2 conntrack file. > That, in general, does not work: > > I am not sure what I am supposed to put in the SOURCE/DESTINATIONcolumns as a "zone" when in reality I don''t care which "zone" this is in (and I don''t think "all" is appropriate). For example, if I want to emulate "-t raw -I PREROUTING 1 -m set --match-set baddies-set src -j DROP" as well as "-t raw -I OUTPUT 1 -m set --match-set baddies-set dst -j DROP" I tried the following:> > 1. > DROP +baddies-set > DROP - +baddies-set > > Doesn''t work - it is asking me for a zone to put in... > > 2. > DROP $FW:+baddies-set > DROP - $FW:+baddies-set > > Moans about unknown zone ("-")...A careful reading of the manpage reveals that a zone is required in the SOURCE column (and ''all'' is appropriate for your use) while a zone is disallowed in the DESTINATION column (remember that the packet hasn''t been routed yet so the destination zone is as yet unknown). Note: When a destination interface is specified, the generated script has to use the routing table to produce a list of destination networks, then generates one rule for each network.> > 3. > DROP $FW:+baddies-set > DROP all $FW:+baddies-set > > I am getting "ERROR: Unknown Interface (fw)" error...Again, no zone in the DESTINATION column.> > Further on this - a few suggestions to extend this file''s functionality: > > 1. I am not sure whether I could use custom action in this file, butit would be very handy if I could. Why? Because if I wish to use such action for creating packet logs to multiple (understand 3) destinations for example, then instead of having 3 separate LOG/NFLOG statements *and* their associate conditionals, I could just have one conditional + custom action, which should, in theory, be translated to a single jump to the corresponding custom-action chain where the multiple packet logs take place. The implementation of actions is heavily integrated with processing of the rules file and is not available in other files. That''s one of the items on my wish list but it will require a large effort.> > 2. If possible, could you include a SWITCH column (similar to what > you already have in "rules") so that this particular rule is switched on/offif/when desired.> > Finally, a side issue I''ve been having, which up until now was a bitof a mystery to me - until I had a proper look at my (default) conntrack file, that is: every time shorewall starts, I get a group of rather annoying syslog messages like so:> xt_CT: No such helper "sane" > xt_CT: No such helper "sane-0" > xt_CT: No such helper "tftp" > xt_CT: No such helper "tftp-0" > xt_CT: No such helper "pptp" > xt_CT: No such helper "sip" > xt_CT: No such helper "sip-0" > xt_CT: No such helper "snmp" > xt_CT: No such helper "netbios-ns" > xt_CT: No such helper "ftp" > xt_CT: No such helper "ftp-0" > xt_CT: No such helper "irc" > xt_CT: No such helper "irc-0" > xt_CT: No such helper "amanda" >> I knew these may have resulted from the fact that I have > intentionallydisabled (and forcibly removed!) all conntrack kernel helper modules. Until I had a look at the conntrack file, I thought that they were caused by shorewall trying to load the ct kernel helper modules, but after seeing all those conditionals in "conntrack" I am not so sure. Is there any way I could get rid of these messages? Am I doing something wrong? These messages are a result of Shorewall probing the system to determine what helpers are available. There are two ways to suppress them: - set LOAD_HELPERS_ONLY=Yes in shorewall.conf. - generate a capabilities file (shorewall show -f capabilities > ${CONFDIR}/shorewall/capabilities), then edit the file to turn off HELPER_MATCH (set the variable to the empty value). -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/21/2012 11:09 AM, Tom Eastep wrote:>> I am not sure what I am supposed to put in the SOURCE/DESTINATION > columns as a "zone" when in reality I don''t care which "zone" this is in > (and I don''t think "all" is appropriate). For example, if I want to > emulate "-t raw -I PREROUTING 1 -m set --match-set baddies-set src -j > DROP" as well as "-t raw -I OUTPUT 1 -m set --match-set baddies-set dst > -j DROP" I tried the following:I just recalled that ''all'' can''t be qualified with an ipset name (or anything else for that matter). Patch attached. With this patch: - ''all'' places the rule in PREROUTING and in OUTPUT - ''all-'' places the rule in PREROUTING - ''$FW'' places the rule in OUTPUT - All of the above can be qualified with ipsets, addresses, etc. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/20/2012 08:18 PM, Mr Dash Four wrote:> > 2. If possible, could you include a SWITCH column (similar to what > you already have in "rules") so that this particular rule is switched > on/off if/when desired. >Will be in Beta 2. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> These will have to wait for Beta 2 -- at that point NFLOG() should work > as you expect and you can specify ''DROP:C_MACRO(info)'' if you want to > make simple ''LOG'' rules log at the ''info'' level.Noted.> Rules in the ALL section come after the blacklist and the > interface-option checks.What I thought initially.> When I want this type of logging, though, I use the ''iptrace'' shorewall > command. This not only logs each packet but traces it through the > Netfilter chains.My situation is different - I must log these packets to 3 different destinations for different reasons - I''d use the "normal" log facility simply to avoid some nasty NFLOG bugs amd as a sort of emergency packup when everything else is screwed, will use NFLOG (class 1) for my main logging tool as this goes across to a different site where all other logs are stored too, will use a 3rd NFLOG statement to capture packet payloads if/when needed and there will be a 4th, optional, log destination using the AUDIT target to be in sync if/when I get SELInux-related alerts so that I don''t spend my time looking through various sources to find out what I am after.> Copy the two attached files into ${SHAREDIR}/shorewall. The new target > is ''Audit'' and accepts one optional parameter (the audit type).It works. You may change the "ERROR: Invalid AUDIT type (XXXXX)" message to indicate what type of audit is acceptable (accept|reject|drop), but that''s a minor thing. Also, personally, I''d prefer this to be "AUDIT" instead of "Audit" for consistency with LOG/NFLOG, but these are semantics really. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> A careful reading of the manpage reveals that a zone is required in the > SOURCE column (and ''all'' is appropriate for your use) while a zone is > disallowed in the DESTINATION column (remember that the packet hasn''t > been routed yet so the destination zone is as yet unknown). > > Note: When a destination interface is specified, the generated script > has to use the routing table to produce a list of destination networks, > then generates one rule for each network.All noted - I must have been half-asleep when testing this last night.> The implementation of actions is heavily integrated with processing of > the rules file and is not available in other files. That''s one of the > items on my wish list but it will require a large effort.It would be nice to have it so that I could extend my logging to this tables with little effort, but if not, I''ll revert to my old friend - "started".> These messages are a result of Shorewall probing the system to determine > what helpers are available. > > There are two ways to suppress them: > > - set LOAD_HELPERS_ONLY=Yes in shorewall.conf.If I do that, according to the man pages, that won''t load my other non-ct modules ("...restricts the set of modules loaded by shorewall to those listed in /var/lib/shorewall/helpers") which isn''t what I want as I have various other modules (not ct-related) which need to me loaded and these are listed in the modules.* files.> - generate a capabilities file (shorewall show -f capabilities > > ${CONFDIR}/shorewall/capabilities), then edit the file to turn off > HELPER_MATCH (set the variable to the empty value).I don''t want to do that either because when I upgrade shorewall, the chances of new capabilities existing in that version which won''t be included in the existing "capabilities" file are pretty high and I am not about to run the update or regenerate all my capabilities file with every shorewall update. Besides, if that turns out to be the case, then I am going to have another shorewall message telling me that my capabilities file is out of date - lose-lose scenario! ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> I just recalled that ''all'' can''t be qualified with an ipset name (or > anything else for that matter). > > Patch attached. > > With this patch: > > - ''all'' places the rule in PREROUTING and in OUTPUT > - ''all-'' places the rule in PREROUTING > - ''$FW'' places the rule in OUTPUT > - All of the above can be qualified with ipsets, addresses, etc.The patch works, but there is one *massive* gotcha: if ipset is used (I assume that would be valid for any other IP address/subnet, ports, protocol values specified there as well) then the rules generated do not flip the src/dst designators around. For example: conntrack ~~~~~~~~~ DROP all:+baddies-set will generate 2 set of iptables statements all showing "baddies-set src" and not, as what seems the more logical thing, create "baddies-set src" for PREROUTING and "baddies-set dst" for OUTPUT, which may not be the initial intention. I seem to remember you had a similar arrangement with the dhcp option in "interfaces" as well as "routestopped". If I were you, I would either change the syntax and make it clearer (perhaps specifying each chain with "O" for OUTPUT, "P" for PREROUTING - similar to what you now have in "secmarks") or keep the existing syntax but place a big, massive warning on the man page, because mistakes such as this would be very easy to make - I know, because that is the first thing I did when tested your patch. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
>> 2. If possible, could you include a SWITCH column (similar to what >> you already have in "rules") so that this particular rule is switched >> on/off if/when desired. >> > > Will be in Beta 2.OK, will have a look then. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/21/12 6:19 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> I just recalled that ''all'' can''t be qualified with an ipset name (or >> anything else for that matter). >> >> Patch attached. >> >> With this patch: >> >> - ''all'' places the rule in PREROUTING and in OUTPUT >> - ''all-'' places the rule in PREROUTING >> - ''$FW'' places the rule in OUTPUT >> - All of the above can be qualified with ipsets, addresses, etc. >The patch works, but there is one *massive* gotcha: > >if ipset is used (I assume that would be valid for any other IP >address/subnet, ports, protocol values specified there as well) then the >rules generated do not flip the src/dst designators around. For example: > >conntrack >~~~~~~~~~ >DROP all:+baddies-set > >will generate 2 set of iptables statements all showing "baddies-set src" >and not, as what seems the more logical thing, create "baddies-set src" >for PREROUTING and "baddies-set dst" for OUTPUT, which may not be the >initial intention. I seem to remember you had a similar arrangement with >the dhcp option in "interfaces" as well as "routestopped".You need two entries if you want to drop traffic to/from +baddies-set: DROP all-:+baddies-set - DROP all +baddies+set So I don''t see anything broken here except that I need to add an example to the manages. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/21/2012 06:19 PM, Mr Dash Four wrote:> It works. You may change the "ERROR: Invalid AUDIT type (XXXXX)" > message to indicate what type of audit is acceptable > (accept|reject|drop), but that''s a minor thing.Done.> Also, personally, I''d prefer this to be "AUDIT" instead of "Audit" > for consistency with LOG/NFLOG, but these are semantics really.You caught me being lazy :) I implemented the feature as an external action rather than as a compiler built-in; that required that the name be distinct from the Netfilter built-in targets. The attached patch implements a built-in named AUDIT. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
>> The patch works, but there is one *massive* gotcha: >> >> if ipset is used (I assume that would be valid for any other IP >> address/subnet, ports, protocol values specified there as well) then the >> rules generated do not flip the src/dst designators around. For example: >> >> conntrack >> ~~~~~~~~~ >> DROP all:+baddies-set >> >> will generate 2 set of iptables statements all showing "baddies-set src" >> and not, as what seems the more logical thing, create "baddies-set src" >> for PREROUTING and "baddies-set dst" for OUTPUT, which may not be the >> initial intention. I seem to remember you had a similar arrangement with >> the dhcp option in "interfaces" as well as "routestopped". > > > You need two entries if you want to drop traffic to/from +baddies-set: > > DROP all-:+baddies-set - > DROP all +baddies+set > > So I don''t see anything broken here except that I need to add an example > to the manages.I didn''t say that it was, because it isn''t. What I did point out to you is that the use of "all" in particular is not as straight-forward as it seems, simply because if source/destination designators are used (either in ipsets, IP addresses or ports) that would be applied in *both* directions in the connection *without* flipping them around. In other words, if I use "all:+baddies-set" (assuming this is one-dimensional set) that would mean match on a source designation (''src'' match) in *both* directions of a particular connection which in 99% of the cases out there wouldn''t be desired. The use of "all-" is not intuitive, unless you can show me how does that relate to the PREROUTING chain? Same goes for "$FW" too. That is why I suggested to you that you either allow the OUTPUT and PREROUTING chains to be explicitly selected - via "O" or "P", or any other, appropriate/suitable/more intuitive options ("all-", "$FW" doesn''t count), in order to avoid this confusion. Case in point of what I''ve just written - your example above. If I find it confusing, and it looks as though the use of "all" and "all-" is confusing you too (or, at least it isn''t as straight-forward to you, to the point that you can make an easy mistake and cock everything up as you did above), than how do you think other, less-knowledgeable, shall we say, shorewall users will find this? ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> The attached patch implements a built-in named AUDIT.It does its job. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/22/12 4:06 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:>>> The patch works, but there is one *massive* gotcha: >>> >>> if ipset is used (I assume that would be valid for any other IP >>> address/subnet, ports, protocol values specified there as well) then >>>the >>> rules generated do not flip the src/dst designators around. For >>>example: >>> >>> conntrack >>> ~~~~~~~~~ >>> DROP all:+baddies-set >>> >>> will generate 2 set of iptables statements all showing "baddies-set >>>src" >>> and not, as what seems the more logical thing, create "baddies-set src" >>> for PREROUTING and "baddies-set dst" for OUTPUT, which may not be the >>> initial intention. I seem to remember you had a similar arrangement >>>with >>> the dhcp option in "interfaces" as well as "routestopped". >> >> >> You need two entries if you want to drop traffic to/from +baddies-set: >> >> DROP all-:+baddies-set - >> DROP all +baddies+set >> >> So I don''t see anything broken here except that I need to add an example >> to the manages. >I didn''t say that it was, because it isn''t. > >What I did point out to you is that the use of "all" in particular is not >as straight-forward as it seems, simply because if source/destination >designators are used (either in ipsets, IP addresses or ports) that would >be applied in *both* directions in the connection *without* flipping them >around. In other words, if I use "all:+baddies-set" (assuming this is >one-dimensional set) that would mean match on a source designation (''src'' >match) in *both* directions of a particular connection which in 99% of >the cases out there wouldn''t be desired. > >The use of "all-" is not intuitive, unless you can show me how does that >relate to the PREROUTING chain? Same goes for "$FW" too. That is why I >suggested to you that you either allow the OUTPUT and PREROUTING chains >to be explicitly selected - via "O" or "P", or any other, >appropriate/suitable/more intuitive options ("all-", "$FW" doesn''t >count), in order to avoid this confusion.The use of ''all'' and ''all-'' is well-established in the rules file where zones must be specified. What I could do is invent a FORMAT 3 which does not accept zones but rather uses a paradigm similar to what you are advocating. I''m not going to mix the two, though.> > >Case in point of what I''ve just written - your example above. > >If I find it confusing, and it looks as though the use of "all" and >"all-" is confusing you too (or, at least it isn''t as straight-forward to >you, to the point that you can make an easy mistake and cock everything >up as you did above), than how do you think other, less-knowledgeable, >shall we say, shorewall users will find thisThe above rules (correcting the obvious typo in the second line) generates these Netfilter rules: Shorewall 4.5.10-Beta2 RAW Table at gateway - Thu Nov 22 17:05:20 PST 2012 Counters reset Thu Nov 22 17:05:16 PST 2012 Chain PREROUTING (policy ACCEPT 56 packets, 6169 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set baddies-set src 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set baddies-set dst Chain OUTPUT (policy ACCEPT 30 packets, 3710 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set baddies-set dst root@gateway:/etc/shorewall# That is exactly what I intended. Packets entering from outside and addressed either to or from members of the baddies-set are dropped. Similarly, traffic originating from the firewall itself and addressed to members of the set are DROPPED. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/22/12 5:19 PM, "Tom Eastep" <teastep@shorewall.net> wrote:>The use of ''all'' and ''all-'' is well-established in the rules file where >zones must be specified. What I could do is invent a FORMAT 3 which does >not accept zones but rather uses a paradigm similar to what you are >advocating. I''m not going to mix the two, though.Patch attached. The ACTION can be suffixed as follows: :O Rule is placed in the OUTPUT chain :OP or PO: Rule is placed in the PREROUTING and OUTPUT chains. :P Rule is placed in the PREROUTING chain. If the suffix is omitted, PREROUTING is assumed. No zone is expected nor accepted in the SOURCE column. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
>> policy ~~~~~~ $FW net DROP:C_MACRO(info) info >> >> This time the message is "ERROR: Default Action Macros may not have >> parameters" > > These will have to wait for Beta 2 -- at that point NFLOG() should work > as you expect and you can specify ''DROP:C_MACRO(info)'' if you want to > make simple ''LOG'' rules log at the ''info'' level.Was this missed from the Beta2 announcement or deliberately left out and not implemented in this Beta? Further on this, the man shorewall-policy tells me that the format of the POLICY column is: POLICY - {ACCEPT|DROP|REJECT|CONTINUE|QUEUE|NFQUEUE[(queuenumber)]|NONE}[:{default-action-or-macro|None}] [...] If the policy is neither CONTINUE nor NONE then the policy may be followed by ":" and one of the following: 1. The word "None" or "none". This causes any default action defined in shorewall.conf[2](5) to be omitted for this policy. 2. The name of a macro. The rules in that macro will be applied before the policy is enforced. This does not require USE_ACTIONS=Yes. Should I assume from the above that I can''t use actions? If so, "default-action-or-macro" should just be "default-macro" instead. If that is not the case, then the format for including custom-or-built-in actions needs to be defined. All that provided macros are allowed. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/25/2012 05:00 AM, Mr Dash Four wrote:> >>> policy ~~~~~~ $FW net DROP:C_MACRO(info) info >>> >>> This time the message is "ERROR: Default Action Macros may not have >>> parameters" >> >> These will have to wait for Beta 2 -- at that point NFLOG() should work >> as you expect and you can specify ''DROP:C_MACRO(info)'' if you want to >> make simple ''LOG'' rules log at the ''info'' level. > Was this missed from the Beta2 announcement or deliberately left out > and not implemented in this Beta?No -- it was implemented; I simply neglected to document it.> Further on this, the man shorewall-policy tells me that the format of the POLICY column is: > > > POLICY - {ACCEPT|DROP|REJECT|CONTINUE|QUEUE|NFQUEUE[(queuenumber)]|NONE}[:{default-action-or-macro|None}] > [...] > If the policy is neither CONTINUE nor NONE then the policy may be followed by ":" and one of the following: > 1. The word "None" or "none". This causes any default action defined in shorewall.conf[2](5) to be omitted for this policy. > 2. The name of a macro. The rules in that macro will be applied before the policy is enforced. This does not require USE_ACTIONS=Yes.The list is incomplete; it should, of course, include an action. It should go on to say that both actions and macros may include parameters; in the case of a macro, the single parameter specifies the log level to be applied to all rules in the macro. Given that specifying a log level affects all rules in the macro (except NFLOG and ULOG), I wouldn''t recommend specifying a log level.> > Should I assume from the above that I can''t use actions?Actions are still allowed. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/25/2012 09:02 AM, Tom Eastep wrote:> On 11/25/2012 05:00 AM, Mr Dash Four wrote: > > Given that specifying a log level affects all rules in the macro (except > NFLOG and ULOG), I wouldn''t recommend specifying a log level. >It would be trivial to restrict the affect of a log level to just bare ''LOG'' rules when a macro is used as a default action. If no one objects, I''ll go ahead and make that change. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/25/2012 09:37 AM, Tom Eastep wrote:> On 11/25/2012 09:02 AM, Tom Eastep wrote: >> On 11/25/2012 05:00 AM, Mr Dash Four wrote: >> >> Given that specifying a log level affects all rules in the macro (except >> NFLOG and ULOG), I wouldn''t recommend specifying a log level. >> > > It would be trivial to restrict the affect of a log level to just bare > ''LOG'' rules when a macro is used as a default action. If no one objects, > I''ll go ahead and make that change.In testing this change, I''m finding that specifying ''macro.Name'' isn''t working correctly. So for now, macros specified as a default action must not have names that conflict with the name of an action. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/25/2012 10:05 AM, Tom Eastep wrote:> On 11/25/2012 09:37 AM, Tom Eastep wrote: >> On 11/25/2012 09:02 AM, Tom Eastep wrote: >>> On 11/25/2012 05:00 AM, Mr Dash Four wrote: >>> >>> Given that specifying a log level affects all rules in the macro (except >>> NFLOG and ULOG), I wouldn''t recommend specifying a log level. >>> >> >> It would be trivial to restrict the affect of a log level to just bare >> ''LOG'' rules when a macro is used as a default action. If no one objects, >> I''ll go ahead and make that change. > > In testing this change, I''m finding that specifying ''macro.Name'' isn''t > working correctly. So for now, macros specified as a default action must > not have names that conflict with the name of an action.Attached are two patches. DEFAULTMACRO1.patch corrects handling of ''macro.Name''. DEFAULTMACRO2.patch limits the application of log levels to bare LOG rules. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> No -- it was implemented; I simply neglected to document it.Indeed. It works, though I have another question regarding macros: since these are included in the chain ''inline'' so to speak, is it possible for a macro to get the name of the chain in which this particular macro is going to be ''inlined''? If that is possible, this would have a good practical use in the SWITCH column of that macro (which is, indeed, implemented) so that I could, for example, use "${chain)_macro_switch" in the SWITCH column. Related to that question, in case what I''ve just suggested is not possible: can I pass more than 1 parameter to a macro?> Actions are still allowed.Yep, that one works too. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
>>>> Given that specifying a log level affects all rules in the macro >>>> (except >>>> NFLOG and ULOG), I wouldn''t recommend specifying a log level. >>>> >>> >>> It would be trivial to restrict the affect of a log level to just bare >>> ''LOG'' rules when a macro is used as a default action. If no one objects, >>> I''ll go ahead and make that change. >> >> In testing this change, I''m finding that specifying ''macro.Name'' isn''t >> working correctly. So for now, macros specified as a default action must >> not have names that conflict with the name of an action. > > Attached are two patches. > > DEFAULTMACRO1.patch corrects handling of ''macro.Name''. > DEFAULTMACRO2.patch limits the application of log levels to bare LOG rules.I am not sure I understand what you are concerned about and what the problem is/was: according to your own macros help page (http://www.shorewall.net/Macros.html - not a dead link this time), if I specify a log level when executing a macro, this propagates to all statements within that macro where log level isn''t specified. I can''t see a problem with that - if I wish to explicitly use a log level for a particular action in a given macro, which is different from the one specified when the macro is executed, then all I have to do is add it as part of that action, i.e.: C_MACRO ~~~~~~~ LOG AUDIT(drop) NFLOG(1,0,1):debug NFLOG(2,0,1) So, when I execute "C_MACRO:info", this translates to: LOG:info AUDIT(drop):info NFLOG(1,0,1):debug # unchanged NFLOG(2,0,1):info Isn''t that so? ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/25/2012 07:08 PM, Mr Dash Four wrote:> >>>>> Given that specifying a log level affects all rules in the macro >>>>> (except >>>>> NFLOG and ULOG), I wouldn''t recommend specifying a log level. >>>>> >>>> >>>> It would be trivial to restrict the affect of a log level to just bare >>>> ''LOG'' rules when a macro is used as a default action. If no one objects, >>>> I''ll go ahead and make that change. >>> >>> In testing this change, I''m finding that specifying ''macro.Name'' isn''t >>> working correctly. So for now, macros specified as a default action must >>> not have names that conflict with the name of an action. >> >> Attached are two patches. >> >> DEFAULTMACRO1.patch corrects handling of ''macro.Name''. >> DEFAULTMACRO2.patch limits the application of log levels to bare LOG rules. > I am not sure I understand what you are concerned about and what the problem is/was: according to your own macros help page (http://www.shorewall.net/Macros.html - not a dead link this time), if I specify a log level when executing a macro, this propagates to all statements within that macro where log level isn''t specified. > > I can''t see a problem with that - if I wish to explicitly use a log level for a particular action in a given macro, which is different from the one specified when the macro is executed, then all I have to do is add it as part of that action, i.e.: > > C_MACRO > ~~~~~~~ > LOG > AUDIT(drop) > NFLOG(1,0,1):debugThat isn''t valid. ''debug'' only applies to the LOG target, not the NFLOG target. So the macro handler already excludes NFLOG from the targets that inherit a level from the macro invocation.> NFLOG(2,0,1) > > So, when I execute "C_MACRO:info", this translates to: > > LOG:info > AUDIT(drop):info > NFLOG(1,0,1):debug # unchanged > NFLOG(2,0,1):info > > Isn''t that so?True. But I''m not sure that is the desired behavior in the context of a default action. Default actions were created primarily to suppress unwanted log noise, not to amplify 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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
>> C_MACRO >> ~~~~~~~ >> LOG >> AUDIT(drop) >> NFLOG(1,0,1):debug >> > > That isn''t valid. ''debug'' only applies to the LOG target, not the NFLOG > target. So the macro handler already excludes NFLOG from the targets > that inherit a level from the macro invocation. >Yeah, I agree - bad example, but you get the gist of it.> True. But I''m not sure that is the desired behavior in the context of a > default action. Default actions were created primarily to suppress > unwanted log noise, not to amplify it. >Why do you have to make a distinction between "default" action/macros and user-defined ones in the context of logging levels? My thinking, as indicated in the previous post, is that if user wants to pass a log level down to all log statements in that macro - they should be able to, let them. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/25/2012 07:08 PM, Mr Dash Four wrote:>> No -- it was implemented; I simply neglected to document it.>> Indeed. It works, though I have another question regarding macros: > since these are included in the chain ''inline'' so to speak, is it > possible for a macro to get the name of the chain in which this > particular macro is going to be ''inlined''?It would be possible but I don''t think that it is desirable. Such a scheme would prevent being able to use the same switch in multiple chains.> > If that is possible, this would have a good practical use in the > SWITCH column of that macro (which is, indeed, implemented) so that I > could, for example, use "${chain)_macro_switch" in the SWITCH column.Again, I''m not in favor of that approach.> Related to that question, in case what I''ve just suggested is not > possible: can I pass more than 1 parameter to a macro? >It is not currently possible but it is something that I would like to do and it would be my preferred approach to providing the capability that you are looking for. If I can get it implemented in the next week, I''ll include it in 4.5.10; otherwise, it will have to wait for 4.5.11. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/26/2012 07:17 AM, Tom Eastep wrote:> On 11/25/2012 07:08 PM, Mr Dash Four wrote: > >> Related to that question, in case what I''ve just suggested is not >> possible: can I pass more than 1 parameter to a macro? >> > > It is not currently possible but it is something that I would like to do > and it would be my preferred approach to providing the capability that > you are looking for. > > If I can get it implemented in the next week, I''ll include it in 4.5.10; > otherwise, it will have to wait for 4.5.11.This capability will be 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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
>> Indeed. It works, though I have another question regarding macros: >> since these are included in the chain ''inline'' so to speak, is it >> possible for a macro to get the name of the chain in which this >> particular macro is going to be ''inlined''? >> > > It would be possible but I don''t think that it is desirable.Eh? Who decides what is "desirable" and what isn''t? If I, as end-user, wish to create a macro, which has different switches for different chains (so that I switch them "on" and "off" if and when I well so please), I could do so, like: M_DROP ~~~~~~~ LOG NFLOG(1,0,1) - .... ${chain}_nflog_drop When the macro is processed, the "${chain}_nflog_drop" switch would be translated to "fw2net_nflog_drop", "net2fw_nflog_drop" and so on, and so forth - different switches for different chains, obviously, and I could selectively turn them "on" and "off" when I damn well please, regardless of whether this is "desirable" or not, simply because it will be my decision, as an administrator of my own firewall, to make. If I need a macro which has the same switch for *all* chains regardless, I could easily use a hard-coded value for the SWITCH column, like so: M_ALL_DROP ~~~~~~~~~~~~ LOG NFLOG(1,0,1) - .... nflog_all_drop So, I don''t see what the issue is here - by allowing the use of this "${chain}" variable (this is just an example, you could use whatever name is more appropriate - you get the point), whoever creates custom macros can decide whether to use this variable in the SWITCH column to switch the set of macros selectively, whether to use a hard-coded value (like my 2nd example above) to switch all macros in one go, or whether not to deploy any switch at all. This should always be a decision for the end-user to make regardless.> Such a > scheme would prevent being able to use the same switch in multiple chains. >How so? If I need a single switch for multiple chains I could use a hard-coded value for the SWITCH column (like in my 2nd example above) and that would be that.> It is not currently possible but it is something that I would like to do > and it would be my preferred approach to providing the capability that > you are looking for. > > If I can get it implemented in the next week, I''ll include it in 4.5.10; > otherwise, it will have to wait for 4.5.11. >The way I see it, this particular feature (passing more than 1 parameter to a macro) goes more and more towards "inlined actions". In other words, actions, which are inlined in the chain they are specified. You may wish to leave the current implementation of a "macro" as it is and add a new type of action (call it inline action or whatever) and start afresh if that would be easier, instead of dragging the millstone of backward compatibility with you by sticking with the old "macro" definition. This, though, is a decision for you to make. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/26/2012 10:55 AM, Mr Dash Four wrote:> >>> Indeed. It works, though I have another question regarding macros: >>> since these are included in the chain ''inline'' so to speak, is it >>> possible for a macro to get the name of the chain in which this >>> particular macro is going to be ''inlined''? >>> >> >> It would be possible but I don''t think that it is desirable. > Eh? Who decides what is "desirable" and what isn''t? > > If I, as end-user, wish to create a macro, which has different switches > for different chains (so that I switch them "on" and "off" if and when I > well so please), I could do so, like: > > M_DROP > ~~~~~~~ > LOG > NFLOG(1,0,1) - .... ${chain}_nflog_drop > >...> You may wish to leave the current implementation of a "macro" as it is > and add a new type of action (call it inline action or whatever) and > start afresh if that would be easier, instead of dragging the millstone > of backward compatibility with you by sticking with the old "macro" > definition. This, though, is a decision for you to make.I misunderstood your original request; I thought that you were asking for the compiler to always qualify switch names by the chain name. What you are proposing above doesn''t work in the general case, given the current compiler architecture. Currently, variable expansion takes place in the preprocessor which has no knowledge of chains, macros, etc. The chain isn''t known until the input line handed to it by the preprocessor is parsed by rule processor. Within the body of a macro or an action, however, the chain name is known. So if we limit the availability of $chain (or whatever we call it), to macro and action bodies, would that meet your needs? -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/26/2012 11:20 AM, Tom Eastep wrote:> On 11/26/2012 10:55 AM, Mr Dash Four wrote: >> >>>> Indeed. It works, though I have another question regarding macros: >>>> since these are included in the chain ''inline'' so to speak, is it >>>> possible for a macro to get the name of the chain in which this >>>> particular macro is going to be ''inlined''? >>>> >>> >>> It would be possible but I don''t think that it is desirable. >> Eh? Who decides what is "desirable" and what isn''t? >> >> If I, as end-user, wish to create a macro, which has different switches >> for different chains (so that I switch them "on" and "off" if and when I >> well so please), I could do so, like: >> >> M_DROP >> ~~~~~~~ >> LOG >> NFLOG(1,0,1) - .... ${chain}_nflog_drop >> >> > ... > >> You may wish to leave the current implementation of a "macro" as it is >> and add a new type of action (call it inline action or whatever) and >> start afresh if that would be easier, instead of dragging the millstone >> of backward compatibility with you by sticking with the old "macro" >> definition. This, though, is a decision for you to make. > > I misunderstood your original request; I thought that you were asking > for the compiler to always qualify switch names by the chain name. > > What you are proposing above doesn''t work in the general case, given the > current compiler architecture. Currently, variable expansion takes place > in the preprocessor which has no knowledge of chains, macros, etc. The > chain isn''t known until the input line handed to it by the preprocessor > is parsed by rule processor. > > Within the body of a macro or an action, however, the chain name is > known. So if we limit the availability of $chain (or whatever we call > it), to macro and action bodies, would that meet your needs?Actually, the chain name is only known within the body of an action or within a macro expansion occurring within the body of an action. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/26/2012 11:20 AM, Tom Eastep wrote:> > What you are proposing above doesn''t work in the general case, given the > current compiler architecture. Currently, variable expansion takes place > in the preprocessor which has no knowledge of chains, macros, etc. The > chain isn''t known until the input line handed to it by the preprocessor > is parsed by rule processor. > > Within the body of a macro or an action, however, the chain name is > known. So if we limit the availability of $chain (or whatever we call > it), to macro and action bodies, would that meet your needs? >Or how about a more focused solution whereby the character ''@'' in a switch name would be replaced by the chain name? Example: NFLOG(1,0,1) net fw ; switch=@_foo would would be the equivalent of: NFLOG(1,0,1) net fw ; switch=net2fw_foo -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> Or how about a more focused solution whereby the character ''@'' in a > switch name would be replaced by the chain name? > > Example: > > NFLOG(1,0,1) net fw ; switch=@_foo > > would would be the equivalent of: > > NFLOG(1,0,1) net fw ; switch=net2fw_foo >That is all excellent, though looking a bit into possible feature expansion/enhancement, where some (other) system/shorewall (internal) resource/variables could be made available to actions/macros in the future, you may need to use the "@" character to indicate a system/shorewall (internal) resource/variable, followed by its name. In our (the only one, at least for now) use-case, this could take the form of "@chain". Possible gotcha, however, is in the case where system variable names and chain names could accidentally overlap, so to play it safe, you may want to use the "@chain@" syntax, or something more suitable (one other possible and very good alternative could be to borrow the bash syntax - "@{chain}"). To summarise: "@chain" (possible gotchas) and/or "@chain@"/"@{chain}" as alternatives to avoid overlaps. Any further resources/variables you wish to make available in the future (one possible candidate I could think of right now could be the current log prefix, like "Shorewall:<chain>:<operation>" used in an action/macros) could easily be expanded to "@something", keeping the consistency. How''s that? ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> Actually, the chain name is only known within the body of an action or > within a macro expansion occurring within the body of an action. >If I use that macro in "rules" or "policy" for example, would the statements in the body of that macro know that chain name? If not, then the way forward, I think, would be for "inline actions" as I suggested in my previous post and keep the "old" macro format and implementation as it is. Any other ideas? ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> I misunderstood your original request;I thought as much.> What you are proposing above doesn''t work in the general case, given the > current compiler architecture. Currently, variable expansion takes place > in the preprocessor which has no knowledge of chains, macros, etc. The > chain isn''t known until the input line handed to it by the preprocessor > is parsed by rule processor. > > Within the body of a macro or an action, however, the chain name is > known. So if we limit the availability of $chain (or whatever we call > it), to macro and action bodies, would that meet your needs? >It would, and I actually think it would be much better. Given your next response, however, that might not be possible. My gut feeling tells me that it would be better to keep the "old" macros the way they are and create a new "inline action" type where more than 1 parameter is allowed (addressed with "$1, $2 etc - the way actions are at present), making internal system/shorewall variable/resource available to that action in the way I suggested in my previous post. I don''t know how doable/difficult this would be as my perl skills are close to nil and I don''t have enough knowledge of the internal shorewall workings to make that judgement - this is a decision you have to take though. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/26/12 3:46 PM, Mr Dash Four wrote:> >> Or how about a more focused solution whereby the character ''@'' in a >> switch name would be replaced by the chain name? >> >> Example: >> >> NFLOG(1,0,1) net fw ; switch=@_foo >> >> would would be the equivalent of: >> >> NFLOG(1,0,1) net fw ; switch=net2fw_foo >> > That is all excellent, though looking a bit into possible feature > expansion/enhancement, where some (other) system/shorewall (internal) > resource/variables could be made available to actions/macros in the > future, you may need to use the "@" character to indicate a > system/shorewall (internal) resource/variable, followed by its name. In > our (the only one, at least for now) use-case, this could take the form > of "@chain". > > Possible gotcha, however, is in the case where system variable names and > chain names could accidentally overlap, so to play it safe, you may want > to use the "@chain@" syntax, or something more suitable (one other > possible and very good alternative could be to borrow the bash syntax - > "@{chain}"). > > To summarise: "@chain" (possible gotchas) and/or "@chain@"/"@{chain}" as > alternatives to avoid overlaps. > > Any further resources/variables you wish to make available in the future > (one possible candidate I could think of right now could be the current > log prefix, like "Shorewall:<chain>:<operation>" used in an > action/macros) could easily be expanded to "@something", keeping the > consistency. How''s that?Let''s start with the simple targeted solution for this release and I will investigate something more elaborate for next release. It can be made backward compatible if we adopt the shell @{...} syntax as the enhanced form. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/26/12 3:46 PM, Mr Dash Four wrote:> >> Actually, the chain name is only known within the body of an action or >> within a macro expansion occurring within the body of an action. >> > If I use that macro in "rules" or "policy" for example, would the > statements in the body of that macro know that chain name? If not, then > the way forward, I think, would be for "inline actions" as I suggested > in my previous post and keep the "old" macro format and implementation > as it is. Any other ideas?When you first asked for something inline (like a macro) as a default action, I took short look at inline actions. Using a macro was cheaper a more foolproof to implement so I chose that approach. I personally think that inline actions are an interesting and useful idea and would like to pursue them in the next release. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/26/12 3:46 PM, Mr Dash Four wrote:> >> I misunderstood your original request; > I thought as much. > >> What you are proposing above doesn''t work in the general case, given the >> current compiler architecture. Currently, variable expansion takes place >> in the preprocessor which has no knowledge of chains, macros, etc. The >> chain isn''t known until the input line handed to it by the preprocessor >> is parsed by rule processor. >> >> Within the body of a macro or an action, however, the chain name is >> known. So if we limit the availability of $chain (or whatever we call >> it), to macro and action bodies, would that meet your needs? >> > It would, and I actually think it would be much better. Given your next > response, however, that might not be possible. > > My gut feeling tells me that it would be better to keep the "old" macros > the way they are and create a new "inline action" type where more than 1 > parameter is allowed (addressed with "$1, $2 etc - the way actions are > at present), making internal system/shorewall variable/resource > available to that action in the way I suggested in my previous post. > > I don''t know how doable/difficult this would be as my perl skills are > close to nil and I don''t have enough knowledge of the internal shorewall > workings to make that judgement - this is a decision you have to take > though.I''ll work on the inline action idea for the next release. Regards, -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> Let''s start with the simple targeted solution for this release and I > will investigate something more elaborate for next release. It can be > made backward compatible if we adopt the shell @{...} syntax as the > enhanced form. >Good enough, I think, though I am not certain if you adopt a single "@" character now to mean "${chain}" (in bash speak), how are you going to expand this later on to, say, "@{something}" - this won''t be backwards compatible at all? ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> When you first asked for something inline (like a macro) as a default > action, I took short look at inline actions. Using a macro was cheaper a > more foolproof to implement so I chose that approach. I personally think > that inline actions are an interesting and useful idea and would like to > pursue them in the next release. >OK, so to provide the chain name in a body of a macro is doable then, I take it? ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/26/12 5:15 PM, Mr Dash Four wrote:> >> Let''s start with the simple targeted solution for this release and I >> will investigate something more elaborate for next release. It can be >> made backward compatible if we adopt the shell @{...} syntax as the >> enhanced form. >> > Good enough, I think, though I am not certain if you adopt a single "@" > character now to mean "${chain}" (in bash speak), how are you going to > expand this later on to, say, "@{something}" - this won''t be backwards > compatible at all?I will expand @{....} first; then any leftover ''@'' characters will be expanded to ${chain}. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/26/12 5:15 PM, Mr Dash Four wrote:> >> When you first asked for something inline (like a macro) as a default >> action, I took short look at inline actions. Using a macro was cheaper a >> more foolproof to implement so I chose that approach. I personally think >> that inline actions are an interesting and useful idea and would like to >> pursue them in the next release. >> > OK, so to provide the chain name in a body of a macro is doable then, I > take it?Yes. -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 \________________________________________________ ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
> I will expand @{....} first; then any leftover ''@'' characters will be > expanded to ${chain}. >Right, got it, makes sense. One other query, this time regarding switches: the man page says that a switch is "on" when its corresponding value in /proc/net/nf_condition is 1. You also have an inversion, so that when something like "!switch_name" is specified, then the switch is "on" when the value is 0 and "off" when that value is 1 (the opposite of the "normal" behaviour). So, if I want a particular switch to be "on" from the start I have, basically, two options: issue "echo 1 > /proc/net_nf_condition/switch_name" in "init", "start" or "started", or, use inversion with "!switch_name". Both of these options are not ideal: with the first option I have to keep track of which option needs to be activated/deactivated, while for the second option, I also need to keep track of what has been inverted. That might be OK for a small number of switches, but when I have a sizeable number of them, this might become more difficult to remember and maintain. What I am getting at is this: would it be possible to have something like "switch_name=1" (you may substitute "1" with "Yes", "True" or "TRUE" if it is easier to process) to indicate the initial value which should be assumed for that switch when shorewall starts? ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov
On 11/27/2012 06:31 AM, Mr Dash Four wrote:> > What I am getting at is this: would it be possible to have something > like "switch_name=1" (you may substitute "1" with "Yes", "True" or > "TRUE" if it is easier to process) to indicate the initial value which > should be assumed for that switch when shorewall starts?I assume that: 1) Only the ''start'' command initializes the switches; other commands leave them as they are? 2) If the same switch is initialized to different values in different rules, then an error message is to be generated? -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 \________________________________________________ ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net
> 1) Only the ''start'' command initializes the switches; other commands > leave them as they are? >Yep, simply because switches, once initialised, are persistent regardless of the state of shorewall, so it would only make sense to initialise them: 1. within "init" inside ''if [ "$COMMAND" = start ]; then''; or 2. within "start" or "started" inside "if [ ! -f "/proc/net/nf_condition/switch_name" ]; then".> 2) If the same switch is initialized to different values in different > rules, then an error message is to be generated? >Hmm, haven''t thought of that - makes sense, not just for "rules", but for various other places where SWITCH column could be used (in the man page describing this functionality you could point out that the initial value could be set in "params", so that this sort of error could be avoided). ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net
On 11/27/2012 03:00 PM, Mr Dash Four wrote:> >> 1) Only the ''start'' command initializes the switches; other commands >> leave them as they are? >> > Yep, simply because switches, once initialised, are persistent > regardless of the state of shorewall, so it would only make sense to > initialise them: 1. within "init" inside ''if [ "$COMMAND" = start ]; > then''; or 2. within "start" or "started" inside "if [ ! -f > "/proc/net/nf_condition/switch_name" ]; then".''init'' won''t work because the switches don''t yet exist before initial ''start''.> >> 2) If the same switch is initialized to different values in different >> rules, then an error message is to be generated? >> > Hmm, haven''t thought of that - makes sense, not just for "rules", but > for various other places where SWITCH column could be used (in the man > page describing this functionality you could point out that the initial > value could be set in "params", so that this sort of error could be > avoided).But then you have to make an entry in "params" for each switch; might as well make it in ''started''. -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 \________________________________________________ ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net
> ''init'' won''t work because the switches don''t yet exist before initial > ''start''. >Ah, right!> But then you have to make an entry in "params" for each switch; might as > well make it in ''started''. >Not necessarily. I could have a parameter called "essential_logging_group=1" and use that for all switches I wish to include in that group (bearing in mind my previous LOG/NFLOG action examples) - it is not 100% fool-proof, but it is a bit more consistent than simply using 0/1, at least in my case. ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net
On 11/27/2012 06:31 AM, Mr Dash Four wrote:> >> I will expand @{....} first; then any leftover ''@'' characters will be >> expanded to ${chain}. >>Given that $0 (and ${0}) expand to the chain name in macros and actions, it seems reasonable to adopt @{0} rather than simply ''@''. Beta 3 implements the simple ''@'' replacement (not documented in the release notes) but I think I''ll change it if there are no objections. Patch 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 \________________________________________________ ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net
> Given that $0 (and ${0}) expand to the chain name in macros and > actions, it seems reasonable to adopt @{0} rather than simply ''@''. > Beta 3 implements the simple ''@'' replacement (not documented in the > release notes) but I think I''ll change it if there are no objections.I don''t see the need for using ''@'' or ''@{0}'' - at least for the time being until you introduce more ''system'' variables in addition to the chain name. If you wish to adopt ''@{X}'' for action parameters (instead of, or in addition to, the current ''$X'' or ''${X}'') then that''s fine, but, for the time being at least, I don''t see the need for this. My two pence, of course. ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net