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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> LOG
Use "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:s0
Patch 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 \________________________________________________
diff --git a/Shorewall/Perl/Shorewall/Tc.pm b/Shorewall/Perl/Shorewall/Tc.pm
index fffe163..5f3cfd6 100644
--- a/Shorewall/Perl/Shorewall/Tc.pm
+++ b/Shorewall/Perl/Shorewall/Tc.pm
@@ -2219,11 +2219,14 @@ sub process_secmark_rule() {
I => 'tcin' ,
O => 'tcout' , );
- my %state = ( N => 'NEW' ,
- I => 'INVALID',
- NI => 'NEW,INVALID',
- E => 'ESTABLISHED' ,
- ER => 'ESTABLISHED,RELATED',
+ my %state = ( N => 'NEW' ,
+ I => 'INVALID',
+ U => 'UNTRACKED',
+ NI => 'NEW,INVALID',
+ NU => 'NEW,UNTRACKED',
+ NIU => 'NEW,INVALID,UNTRACKED',
+ E => 'ESTABLISHED' ,
+ ER => 'ESTABLISHED,RELATED',
);
my ( $chain , $state, $rest) = split ':', $chainin , 3;
diff --git a/Shorewall/Perl/Shorewall/Raw.pm b/Shorewall/Perl/Shorewall/Raw.pm
index 03dca0a..ae1c027 100644
--- a/Shorewall/Perl/Shorewall/Raw.pm
+++ b/Shorewall/Perl/Shorewall/Raw.pm
@@ -80,7 +80,7 @@ sub process_conntrack_rule( $$$$$$$$$ ) {
# Netfilter development list
#
$action = 'CT --notrack' if have_capability 'CT_TARGET';
- } else {
+ } elsif ( $action ne 'DROP' ) {
( $target, my ( $option, $args, $junk ) ) = split ':', $action, 4;
fatal_error "Invalid notrack ACTION ( $action )" if $junk || $target ne
'CT';
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
