Re: [Shorewall-devel] Shorewall 4.5.10 Beta 1
Tom The attached config. generates the following iptables rule: -A eth0_fwd -m conntrack --ctstate NEW,INVALID,UNTRACKED -j ~excl5 which produces the following error message: iptables-restore v1.4.15: Couldn't load target `~excl5':No such file or directory Note, if OPTIMIZE=0 is specified, the error does not occur. Steven. shorewall2A3.tar.gz Description: application/compressed-tar -- 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___ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
Re: [Shorewall-devel] various bugs and suggestions (v4.5.9+)
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 \
#
# Shorewall 4 - AUDIT Action
#
#/usr/share/shorewall/action.AUDIT
#
# This program is under GPL
[http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt]
#
# (c) 2011 - Tom Eastep (teas...@shorewall.net)
#
# Complete documentation is available at http://shorewall.net
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of Version 2 of the GNU General Public License
# as published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
#
# AUDIT[(type)]
#
# Default type is drop
#
##
FORMAT 2
DEFAULTS drop
BEGIN PERL;
use Shorewall::IPAddrs;
use Shorewall::Config;
use Shorewall::Chains;
my ( $type ) = get_action_params( 1 );
fatal_error "Invalid AUDIT type ($type)" unless $type =~
/^(?:accept|drop|reject)$/;
require_capability('AUDIT_TARGET', 'The AUDIT action', 's');
my $chainref = get_action_chain;
add_ijump( $chainref, j=> 'AUDIT', targetopts => "--type $type" );
allow_optimize( $chainref );
Re: [Shorewall-devel] various bugs and suggestions (v4.5.9+)
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/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 ("-")...
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, 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.
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/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?
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
___
Shorewall-devel mailing list
Shorewall-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
Re: [Shorewall-devel] various bugs and suggestions (v4.5.9+)
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 \
diff --git a/Shorewall/Perl/Shorewall/Raw.pm b/Shorewall/Perl/Shorewall/Raw.pm
index ae1c027..ddc19cf 100644
--- a/Shorewall/Perl/Shorewall/Raw.pm
+++ b/Shorewall/Perl/Shorewall/Raw.pm
@@ -54,7 +54,9 @@ sub process_conntrack_rule( $ ) {
my $zone;
my $restriction = PREROUTE_RESTRICT;
-unless ( $chainref ) {
+if ( $chainref ) {
+ $restriction = OUTPUT_RESTRICT if $chainref->{name} eq 'OUTPUT';
+} else {
#
# Entry in the conntrack file
#
@@ -248,10 +250,10 @@ sub setup_conntrack() {
$empty = 0;
- if ( $source eq 'all' ) {
- for my $zone (all_zones) {
- process_conntrack_rule( undef, undef, $action, $zone, $dest, $proto, $ports, $sports, $user );
- }
+ if ( $source =~ /^all(-)?(:(.+))?$/ ) {
+ fatal_error 'USER/GROUP is not allowed unless the SOURCE zone is $FW or a Vserver zone' if $user ne '-';
+ process_conntrack_rule( $raw_table->{OUTPUT}, undef, $action, $3 || '-', $dest, $proto, $ports, $sports, $user ) unless $1;
+ process_conntrack_rule( $raw_table->{PREROUTING}, undef, $action, $3 || '-', $dest, $proto, $ports, $sports, $user );
} else {
process_conntrack_rule( undef, undef, $action, $source, $dest, $proto, $ports, $sports, $user );
}
--
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___
Shorewall-devel mailing list
Shorewall-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
Re: [Shorewall-devel] various bugs and suggestions (v4.5.9+)
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 ___ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
Re: [Shorewall-devel] various bugs and suggestions (v4.5.9+)
> 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 (X)" 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
___
Shorewall-devel mailing list
Shorewall-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
Re: [Shorewall-devel] various bugs and suggestions (v4.5.9+)
>> 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 ___ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
Re: [Shorewall-devel] various bugs and suggestions (v4.5.9+)
> 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 ___ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
Re: [Shorewall-devel] various bugs and suggestions (v4.5.9+)
> 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
___
Shorewall-devel mailing list
Shorewall-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
Re: [Shorewall-devel] various bugs and suggestions (v4.5.9+)
On 11/21/12 6:19 PM, "Mr Dash Four" 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: DROPall-:+baddies-set - DROPall +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 ___ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
