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
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
