On 09/01/2012 06:00 AM, Mr Dash Four wrote:
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!".
Patch CONF.patch attached.
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.
Are you referring to the inconsistency mentioned in the release notes
'Migration Considerations' section? If not, then I'm not following what
problem that you are reporting.
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.
Patch RTSTOPPED.patch attached.
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.
The 'modules.dep' file isn't located via PATH, AFAIK. It is assumed to
be located in /lib/modules/<current-kernel-version>.
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.
Done.
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.
For those that are worried about this issue, I suggest omitting the
'dhcp' option from the interfaces file and adding explicit DHCP rules in
the rules and routestopped files.
I will add a warning in the manpages.
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!
I'm unable to reproduce the above result. Do you have a simple test case?
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
Corrected.
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.
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 ;;
As I understand it, the Fedora init file standards require separate entries.
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?).
Corrected.
10. Shorewall-init: shorewall-init integration with network up/down
scripts (but NOT NetworkManager) is non-existent!
The installer installs the ifupdown script as ${SBINDIR}/ifup-local and
${SBINDIR}/ifdown-local if those files don't already exist.
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).
I really should deprecate the 'try' command as it duplicates the
functionality of the 'safe-start' and 'safe-restart' commands.
[-options] is the same as in any command and is explained at the top in
the 'Options' section.
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)
That's actually a bug -- patch IPSET.patch attached.
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?
If a compiled script doesn't exist, then there is nothing for
shorewall-init to do. The whole point of Shorewall-init is to execute a
'shorewall stop' prior to starting networking. If there is no compiled
script, then there is no way to issue a 'stop' command.
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).
I don't see the point of that. On any system that has the Shorewall
package installed, ${VARDIR} should survive a reboot and there should be
a compiled script already present. Are you actually running the full
Shorewall package on a system where ${VARDIR} is in ram disk?
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.
Neither reload nor restart involves a 'stop'. What can speed up systems
that have the full Shorewall package installed is to set AUTOMAKE=Yes.
This recompiles the firewall only if there is a file on the CONFIG_PATH
that is newer than the compiled firewall.
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?
There is currently no way to do that. What sort of modifications are you
planning? Might new Shorewall features meet this need?
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.
I'll put that on the todo list.
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)
I'll see what I can do.
-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 \________________________________________________
diff --git a/Shorewall-core/lib.cli b/Shorewall-core/lib.cli
index ef1995a..3cf4fcb 100644
--- a/Shorewall-core/lib.cli
+++ b/Shorewall-core/lib.cli
@@ -3139,7 +3139,7 @@ shorewall_cli() {
g_shorewalldir=
VERBOSE=
- VERBOSITY=
+ VERBOSITY=1
[ -n "$g_lite" ] || . ${g_basedir}/lib.cli-std
diff --git a/Shorewall/lib.cli-std b/Shorewall/lib.cli-std
index 2f68ce9..7f23ff3 100644
--- a/Shorewall/lib.cli-std
+++ b/Shorewall/lib.cli-std
@@ -34,8 +34,6 @@ get_config() {
ensure_config_path
-
-
if [ "$1" = Yes ]; then
params=$(find_file params)
@@ -378,7 +376,7 @@ compiler() {
#
# Get the config from $g_shorewalldir
#
- [ -n "$g_shorewalldir" -a "$g_shorewalldir" != ${g_confdir} ] && get_config
+ get_config Yes
case $COMMAND in
*start|try|refresh)
@@ -1648,7 +1646,6 @@ compiler_command() {
case $COMMAND in
compile)
- get_config Yes
shift
compile_command $@
;;
@@ -1658,7 +1655,6 @@ compiler_command() {
refresh_command $@
;;
check)
- get_config Yes
shift
check_command $@
;;
diff --git a/Shorewall/Perl/Shorewall/Misc.pm b/Shorewall/Perl/Shorewall/Misc.pm
index 2d9d7d9..a8ba902 100644
--- a/Shorewall/Perl/Shorewall/Misc.pm
+++ b/Shorewall/Perl/Shorewall/Misc.pm
@@ -634,7 +634,6 @@ sub process_routestopped() {
my $rule = shift @rule;
add_rule $filter_table->{INPUT}, "$sourcei $source $rule -j ACCEPT", 1;
- add_rule $filter_table->{OUTPUT}, "$desti $dest $rule -j ACCEPT", 1 unless $config{ADMINISABSENTMINDED};
my $matched = 0;
@@ -644,6 +643,7 @@ sub process_routestopped() {
}
if ( $dest{$host} ) {
+ add_rule $filter_table->{OUTPUT}, "$desti $dest $rule -j ACCEPT", 1 unless $config{ADMINISABSENTMINDED};
add_rule $filter_table->{FORWARD}, "$desti $dest $rule -j ACCEPT", 1;
$matched = 1;
}
diff --git a/Shorewall/Perl/Shorewall/Misc.pm b/Shorewall/Perl/Shorewall/Misc.pm
index a8ba902..5cc4ed8 100644
--- a/Shorewall/Perl/Shorewall/Misc.pm
+++ b/Shorewall/Perl/Shorewall/Misc.pm
@@ -574,8 +574,7 @@ sub process_routestopped() {
my $rule = do_proto( $proto, $ports, $sports, 0 );
for my $host ( split /,/, $hosts ) {
- fatal_error "Ipsets not allowed with SAVE_IPSETS=Yes" if $host =~ /^!?\+/ && $config{SAVE_IPSETS};
- validate_host $host, 1;
+ imatch_source_net( $host );
push @hosts, "$interface|$host|$seq";
push @rule, $rule;
}
------------------------------------------------------------------------------
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
