They are all relevant to v4.5.6, haven't checked the latest version to see if
they have been fixed, so apologies if they have...
BUGS
~~~~
1. Shorewall-lite: From an arbitrary directory where shorewall-lite files are
to be compiled (i.e. "~/shorewall-lite/dmz" for example): "shorewall compile -T
-p -e ." produces the following error:
"/etc/shorewall/shorewall.conf does not exist!".
Well, /etc/shorewall/shorewall.conf is the config file for the HOST system and
shorewall should NOT be using this file! This is "corrected" by adding "." at
the beginning of ${SHAREDIR}/shorewall/configdir file, but then comes the next
error:
"ERROR: . is a directory".
The correct syntax, according to shorewall, is "compile [ -e ] [ -p ] [ -t ] [
-d ] [ -T ] [ <directory name> ] [ <path name> ]", so this should be accepted.
As a work-around, executing "shorewall compile -T -p -e . firewall" works, but
then the "firewall" file produced by "shorewall compile -T -p -e . firewall"
ignores CONFIG_PATH, CONFDIR and SHAREDIR and uses these settings from the HOST
system.
In other words, firewall::g_confdir, firewall::g_basedir, firewall::CONFIG_PATH
and firewall::VARDIR are all taken from the host system's shorewallrc file in
the firewall::initialize function, which is wrong.
Even if I force the use of a locally-built shorewallrc file to reflect the
REMOTE system's layout "shorewall compile -T -p -e . firewall" fails miserably
as it could not find its lib.core file.
Yeah, a classic chicken and egg scenario!
The compiled "firewall" script should take into account the layout of the
remote system (maybe by including a separate copy of shorewallrc build for the
REMOTE system) and not have all these mickey-mouse g_* variables assuming
hard-coded values, particularly as "firewall" is executable script and could,
in theory, be used where nothing else is available on the remote system - as is
the case with most embedded/resource-constrained systems where nothing else is
present.
2. Shorewall-lite: shorewall-lite produces erroneous "firewall" file as it
references VARDIR instead of VARDIR/shorewall-lite, resulting in an unholy
mess! There seems to be a great deal of inconsistency in various shorewall
products where sometimes VARDIR is assumed to be, say, "/var/lib", and in other
cases this refers to "/var/lib/$product".
With shorewall-lite, VARDIR is usually assumed to be /var/lib/shorewall-lite,
but then when I get to assign VARDIR in shorewallrc with
/var/lib/shorewall-lite I get this during start:
ERROR: Shorewall Lite is not properly installed
The file /opt/var/lib/shorewall-lite/shorewall-lite/firewall does not
exist
The culprit seems to be in lib.base:
VARDIR=${VARDIR}/${g_program}
So, as I mentioned above, VARDIR seems to be carrying inconsistent definitions
across shorewall products which needs to be fixed.
3. Shorewall(-lite): routestopped produces wrong firewall rules. Example:
#INTERFACE HOST(S) OPTIONS PROTO DEST
SOURCE
# PORT(S)
PORT(S)
eth0 10.1.1.17,10.2.1.3 source tcp 22,5432
should produce one-sided (source) rules, but I see this:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp -- eth0 * 10.1.1.17 0.0.0.0/0
multiport dports 22,5432
0 0 ACCEPT tcp -- eth0 * 10.2.1.3 0.0.0.0/0
multiport dports 22,5432
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
ctstate RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 10.1.1.17
multiport dports 22,5432
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 10.2.1.3
multiport dports 22,5432
Note "dports" in both INPUT and OUTPUT chains. If anything, thse should change
directions (dports for INPUT, sports in OUTPUT). Using different "source" and
"destination" OPTIONS makes matters worse as it produces twice as many rules
for each direction, which is madness.
4. Shorewall-lite: In systems where I use a different "PATH" (as in the bash
PATH variable for searching executables), modprobe statement in modules.* fails
to load ip_tables_raw ("modules.dep cannot be found" error) - I suspect there
is assumed path ("/sbin:/bin" etc) somewhere within the shorewall lib files and
not what I have specified in my shorewall(-lite).conf.
I found the "path" to be hard-coded in two separate statements in lib.cli.
lib.common loads the actual kernel modules directly using "insmod" or
"modprobe" (no path!) depending on whether "modprobe" could be found.
Also, ip_table_raw module needs to be added to
${SHAREDIR}/shorewall-lite/modules.essential so that it is loaded at startup.
The same probably goes for all other shorewall products as well.
5. Shorewall(-lite): Add a message that the 'blacklist' option in
zones/interfaces is DEPRECATED in favour of blrules (well, at least no
'blacklist' template file is provided), so that I don't get confused by adding
that option and thinking that it is in any way related to blrules, because it
isn't.
6. Shorewall(-lite): Allow for 'dhcp' option to specify a specific
host/broadcast address(es) to be used when dhcp address is obtained. As it
stands, the current implementation presents a security risk. Suppose I have a
single interface, which gets its IP address from my ISP and needs to connect to
a specific host or use a specific broadcast addresses. By specifying the 'dhcp'
in interfaces option I get this, among other things:
-A INPUT -p udp --dport 67:68 -i eth0 -j ACCEPT
-A FORWARD -p udp --dport 67:68 -i eth0 -o eth0 -j ACCEPT
-A OUTPUT -p udp --dport 67:68 -o eth0 -j ACCEPT
[...]
-A eth0_iop -p udp --dport 67:68 -j ACCEPT
If eth0 faces the internet ANYONE could connect to my firewall (and the
firewall can connect to ANY host) on ports 67:68 as there is no restriction put
in place. This is also valid when routestopped is used, so it needs to be
corrected.
Also, I do not see much difference between the first statement above and the
last, which executes in the net2fw chain, which in turn, is part of INPUT. In
other words, I have this:
-A INPUT -p udp --dport 67:68 -i eth0 -j ACCEPT
-A INPUT -i eth0 -j net2fw
[...]
-A net2fw -m conntrack --ctstate NEW,INVALID -j ~blacklist0 -m comment
--comment "BLACKLIST"
-A net2fw -i eth0 -j eth0_iop
[...]
-A eth0_iop -m conntrack --ctstate NEW,INVALID -j smurfs
-A eth0_iop -p udp --dport 67:68 -j ACCEPT
The last statement above is exactly the same as the first!
7. Shorewall-init: shorewallrc discrepancies in shorewall-init and the rest of
the shorewall products:
/etc/rc.d/init.d/shorewall-init:
if [ -f ~/.shorewallrc ]; then
. ~/.shorewallrc || exit 1
else
SBINDIR=/sbin
SYSCONFDIR=/etc/default
VARDIR=/var/lib
fi
/etc/rc.d/init.d/shorewall:
. /usr/share/shorewall/shorewallrc
8. Shorewall-init: /etc/rc.d/init.d/shorewall-init lists its usage as
"/etc/init.d/shorewall-init {start|stop}", but "status" is also accepted. This
needs to be corrected.
9. Shorewall-init: From Fedora's perspective (don't know about any other
distros - this might be applicable there also) the init.d script contains the
following:
restart|reload|force-reload)
echo "Not implemented"
exit 3
;;
condrestart|try-restart)
echo "Not implemented"
exit 3
;;
The above could be collapsed into:
restart|reload|force-reload|condrestart|try-restart)
echo "Not implemented"
exit 3
;;
Also, the "OPTIONS" variable is unused so it should be removed. Same goes for
"vardir" in both start() and stop().
Not to mention that all those "[ retval -ne 0 ]" statements are not going to
lead anywhere - "retval" should actually be "$retval", ideally as "[[ $retval
!= 0 ]]" (which incompetent idiot wrote this script?).
10. Shorewall-init: shorewall-init integration with network up/down scripts
(but NOT NetworkManager) is non-existent!
11. Shorewall: shorewall [trace|debug [nolock]] [-options] try directory
[timeout] [-options] is not explained in the shorewall man page and neither is
the "directory" parameter (which I guesed it to be the configuration directory).
SUGGESIONS:
~~~~~~~~~~~
1. ipsets not allowed in routestopped (why?). When used, I get this:
ERROR: An ipset name (+test) is not allowed in this context
Using multi-dimensional sets isn't allowed either (invalid set name "+test[dst"
error is given)
2. Shorewall-init: help & man pages advice for execution of "shorewall compile"
prior to executing /etc/rc.d/init.d/shorewall-init so that
${VARLIB}/$product/firewall is present. Indeed, shorewall-init checks for this
in start() and if the file is not present it does absolutely nothing.
What is the sense in that? Since shorewall-init normally starts before the
network or the shorewall "product" is brought up, how am I supposed to compile
that "firewall" script exactly?
start() should include a "shorewall compile" in one form or another, or, at the
very least execute the $product init script with "compile" option (that new
"compile" options should, of course, be implemented).
3. Shorewall: At least with the Fedora-based scripts, reload|restart etc could
be replaced with "try", particularly as stop/restart may not be needed and can
be performed "automatically" by shorewall when "try" is specified.
4. I would like to be able to execute a bash script which *modifies* the
compiled "firewall" file before Shorewall starts or is reloaded. Is it possible
for this to be implemented somehow?
5. Allow multiple owners to be specified in the rules (and all other relevant
files), like "root,kids" for example. Currently I am unable to do that and have
to generate the same rules with different owners, which is a bit of a pain.
6. Shorewall(-lite): The following could be optimised:
interfaces
~~~~~~~~~~
vpn eth1
arp_filter=1,arp_ignore=2,logmartians=1,nets=10.1.1.0/24,nosmurfs,routefilter=1,tcpflags
red eth2 arp_filter=1,arp_ignore=2,logmartians=1,nosmurfs,routefilter=1,tcpflags
Produces:
-A vpn2net -s 10.1.1.0/24 -m conntrack --ctstate NEW,INVALID -j smurfs
-A vpn2net -m conntrack --ctstate NEW,INVALID -j smurfs
[...]
-A vpn2net -p tcp -s 10.1.1.0/24 -j tcpflags
-A vpn2net -p tcp -j tcpflags
This could be optimised to just the second line in both statements above (I
have OPTIMIZE=15 in shorewall.conf)
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
