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/
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/shorewallrcCorrected.> > 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 \________________________________________________ ------------------------------------------------------------------------------ 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/
On 09/01/2012 10:51 AM, Tom Eastep wrote:> >> 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.Patch attached. -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
> Patch CONF.patch attached.Will look into it when I have the time.>> 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.No. The problem is that VARDIR has different definition, depending on what shorewall product is deployed, which is wrong. For example, VARDIR in shorewall is (usually) /var/lib, in shorewall-lite is /var/lib/shorewall-lite. To top it all off (and that is particularly glaring in shorewall-lite''s case), in some parts of the compiled firewall file (which incorporates various custom files, like params, rules etc) VARDIR is referred to as /var/lib, but in others it is assumed to be /var/lib/shorewall-lite. Also, in shorewall-lite''s case, at the very beginning of the "firewall" execution, there was a bunch of hard-coded values of these variables, causing me a lot of headaches, particularly as I wasn''t using "standard" directories. What I did though (and I think this should be the approach adopted), is to source shorewallrc and wipe out any hard-coded values for these variables. I also had to change the "VARDIR=${VARDIR}/${g_program}" assignment as shown above in order to keep the consistency, otherwise I was getting the above error. Hope it is clear, if not, I have to dig up a test case up.> Patch RTSTOPPED.patch attached.Will look into it when I have the time.> >> 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>.Quite right, but the "modprobe" command I was using was a bloody busybox abomination and that was executing simply because shorewall was assuming (or, rather, hard-coding) pre-defined paths, like /sbin and /bin. If shorewall was honouring the path variables as I specified in my shorewall.conf file, it would have executed *my* version of modprobe (which, incidentally, was in /opt/sbin and compiled *specifically* to look for kernel modules in /opt/lib/modules/<kernel-version>, together with the correct modules.dep), thus avoiding the problem I described above.> Done.Thanks.> 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.This is precisely what I have done. I initially "trusted" this option, though, decided to check and see what the effect of deploying it is and I am glad I did, because I realised what was happening.> I will add a warning in the manpages.I am not sure that would be enough. You are opening a pinhole in the firewall and warning users about it. There are quite a few gullible individuals out there who either won''t pay attention to this warning or worse. My advice would be to either remove it completely or allow it to be specified with parameters (similar to "nets", i.e. dhcp=255.255.255.255,10.1.1.17).>> 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?I''ll prepare a test case when I have more time.>> 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.Separate entries for what? As it stands, all 6 conditionals are collapsed into two equal set of statements. I don''t see a problem of going a step further and collapsing them all into one.> I really should deprecate the ''try'' command as it duplicates the > functionality of the ''safe-start'' and ''safe-restart'' commands.Are they the same? What I like about "try" is that it starts the firewall regardless of the state it was in (perfect when I don''t care what that state was). Can I achieve the same with safe-start then?> That''s actually a bug -- patch IPSET.patch attached.Thanks, will check it when I have the time.> 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.Quite right, but executing "shorewall stop" requires the firewall script and since shorewall-init is usually brought up before networking and the "standard" shorewall, there is no way for this "firewall" script to materialise since nothing has been run prior to shorewall-init - the point I was trying to make above.>> 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?OK, let me explain my use case. On one of my machines I have 7 interfaces, 2 of which *must* be up when the system is brought alive (one uses dhcp to obtain its lease, the other is a vpn to a different location), the rest of the interfaces are brought up in the standard way (ifup). For security and performance reasons, I have the whole disk image loaded into ram, with the exception of the security auditing daemon, SELinux, syslog-ng logs and some non-essential system settings, which survive the reboot. The rest is completely lost. The whole root (/) is completely locked and even though changes are "made" to all files, none of these survive the reboot with the exceptions I just mentioned. So, in order to "lock" my firewall *before* the 2 interfaces (or anything else) are brought up, what I currently do is compile my shorewall script (shorewall compile), then execute shorewall-init, then bring up the 2 interfaces, bring the rest of the network up and finally start shorewall. This is done so that between the time the 2 interfaces are brought up (and my firewall is completely open) and the rest of the network starts, I would like everything to be locked out and only the essential stuff to be let in. The second reason to do this (which I can''t implement at present since the integration with ifup/ifdown and shorewall-init seems unworkable) is if any of the 2 interfaces changes its status (goes down, changes its IP address etc), I have to repeat the above steps and secure the firewall first until either these interfaces sort themselves out, or, someone logs in (via ssh) to clear the mess.>> 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?The stuff I am trying to do is *highly* experimental and not (yet) mainstream. I''ll email you privately with the details. ------------------------------------------------------------------------------ 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/
>> I''ll see what I can do. > > Patch attached.Thanks, I''ll look into it when time permits. ------------------------------------------------------------------------------ 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/
On 09/01/2012 07:29 PM, Mr Dash Four wrote:>> Patch CONF.patch attached. > Will look into it when I have the time. > >>> 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. > No. The problem is that VARDIR has different definition, depending on what shorewall product is deployed, which is wrong. > > For example, VARDIR in shorewall is (usually) /var/lib, in shorewall-lite is /var/lib/shorewall-lite. To top it all off (and that is particularly glaring in shorewall-lite''s case), in some parts of the compiled firewall file (which incorporates various custom files, like params, rules etc) VARDIR is referred to as /var/lib, but in others it is assumed to be /var/lib/shorewall-lite. > > Also, in shorewall-lite''s case, at the very beginning of the "firewall" execution, there was a bunch of hard-coded values of these variables, causing me a lot of headaches, particularly as I wasn''t using "standard" directories. What I did though (and I think this should be the approach adopted), is to source shorewallrc and wipe out any hard-coded values for these variables. I also had to change the "VARDIR=${VARDIR}/${g_program}" assignment as shown above in order to keep the consistency, otherwise I was getting the above error. Hope it is clear, if not, I have to dig up a test case up. > > >> Patch RTSTOPPED.patch attached. > Will look into it when I have the time. > >> >>> 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>. > Quite right, but the "modprobe" command I was using was a bloody busybox abomination and that was executing simply because shorewall was assuming (or, rather, hard-coding) pre-defined paths, like /sbin and /bin. > > If shorewall was honouring the path variables as I specified in my shorewall.conf file, it would have executed *my* version of modprobe (which, incidentally, was in /opt/sbin and compiled *specifically* to look for kernel modules in /opt/lib/modules/<kernel-version>, together with the correct modules.dep), thus avoiding the problem I described above. > >> Done. > Thanks. > >> 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. > This is precisely what I have done. I initially "trusted" this option, though, decided to check and see what the effect of deploying it is and I am glad I did, because I realised what was happening. > >> I will add a warning in the manpages. > I am not sure that would be enough. You are opening a pinhole in the firewall and warning users about it. There are quite a few gullible individuals out there who either won''t pay attention to this warning or worse. My advice would be to either remove it completely or allow it to be specified with parameters (similar to "nets", i.e. dhcp=255.255.255.255,10.1.1.17). > > >>> 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? > I''ll prepare a test case when I have more time. > >>> 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. > Separate entries for what? As it stands, all 6 conditionals are collapsed into two equal set of statements. I don''t see a problem of going a step further and collapsing them all into one. > >> I really should deprecate the ''try'' command as it duplicates the >> functionality of the ''safe-start'' and ''safe-restart'' commands. > Are they the same? What I like about "try" is that it starts the firewall regardless of the state it was in (perfect when I don''t care what that state was). Can I achieve the same with safe-start then? > > >> That''s actually a bug -- patch IPSET.patch attached. > Thanks, will check it when I have the time. > >> 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. > Quite right, but executing "shorewall stop" requires the firewall script and since shorewall-init is usually brought up before networking and the "standard" shorewall, there is no way for this "firewall" script to materialise since nothing has been run prior to shorewall-init - the point I was trying to make above. > >>> 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? > OK, let me explain my use case. > > On one of my machines I have 7 interfaces, 2 of which *must* be up when the system is brought alive (one uses dhcp to obtain its lease, the other is a vpn to a different location), the rest of the interfaces are brought up in the standard way (ifup). > > For security and performance reasons, I have the whole disk image loaded into ram, with the exception of the security auditing daemon, SELinux, syslog-ng logs and some non-essential system settings, which survive the reboot. The rest is completely lost. The whole root (/) is completely locked and even though changes are "made" to all files, none of these survive the reboot with the exceptions I just mentioned. > > So, in order to "lock" my firewall *before* the 2 interfaces (or anything else) are brought up, what I currently do is compile my shorewall script (shorewall compile), then execute shorewall-init, then bring up the 2 interfaces, bring the rest of the network up and finally start shorewall. > > This is done so that between the time the 2 interfaces are brought up (and my firewall is completely open) and the rest of the network starts, I would like everything to be locked out and only the essential stuff to be let in. > > The second reason to do this (which I can''t implement at present since the integration with ifup/ifdown and shorewall-init seems unworkable) is if any of the 2 interfaces changes its status (goes down, changes its IP address etc), I have to repeat the above steps and secure the firewall first until either these interfaces sort themselves out, or, someone logs in (via ssh) to clear the mess. > >>> 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? > The stuff I am trying to do is *highly* experimental and not (yet) mainstream. I''ll email you privately with the details. > > > ------------------------------------------------------------------------------ > 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 > Shorewall-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-devel >-- 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 \________________________________________________ ------------------------------------------------------------------------------ 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/
Please disregard my last post -- I inadvertently hit <send> (haven''t had my coffee yet this morning). -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
On 09/02/2012 07:04 AM, Tom Eastep wrote:> On 09/01/2012 07:29 PM, Mr Dash Four wrote:>>> 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. >> No. The problem is that VARDIR has different definition, depending >> on what shorewall product is deployed, which is wrong. >> >> For example, VARDIR in shorewall is (usually) /var/lib, in >> shorewall-lite is /var/lib/shorewall-lite. To top it all off (and >> that is particularly glaring in shorewall-lite''s case), in some >> parts of the compiled firewall file (which incorporates various >> custom files, like params, rules etc) VARDIR is referred to as >> /var/lib, but in others it is assumed to be >> /var/lib/shorewall-lite. >> >> Also, in shorewall-lite''s case, at the very beginning of the >> "firewall" execution, there was a bunch of hard-coded values of >> these variables, causing me a lot of headaches, particularly as I >> wasn''t using "standard" directories. What I did though (and I think >> this should be the approach adopted), is to source shorewallrc and >> wipe out any hard-coded values for these variables. I also had to >> change the "VARDIR=${VARDIR}/${g_program}" assignment as shown >> above in order to keep the consistency, otherwise I was getting the >> above error. Hope it is clear, if not, I have to dig up a test case >> up.Here is a diff between two compiled scripts; ''firewall'' is compiled for Shorewall and ''firewall1'' is compiled for Shorewall-lite. They used the same shorewallrc file and capabilities: --- firewall 2012-09-02 07:05:27.160915598 -0700 +++ firewall1 2012-09-02 07:06:17.880277969 -0700 @@ -1,6 +1,6 @@ #!/bin/sh # -# Compiled firewall script generated by Shorewall 4.5.7 - Sun Sep 2 07:05:27 2012 +# Compiled firewall script generated by Shorewall 4.5.7 - Sun Sep 2 07:06:17 2012 # # This program is under GPL [http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt] # @@ -1963,13 +1963,13 @@ # These variables are required by the library functions called in this script # g_family=4 - g_confdir=/etc/shorewall - g_product=Shorewall - g_program=shorewall - g_basedir=/usr/share/shorewall - CONFIG_PATH="/etc/shorewall:/usr/share/shorewall" + g_confdir=/etc/shorewall-lite + g_product="Shorewall Lite" + g_program=shorewall-lite + g_basedir=/usr/share/shorewall-lite + CONFIG_PATH="/etc/shorewall-lite:/usr/share/shorewall-lite" [ -f ${g_confdir}/vardir ] && . ${g_confdir}/vardir - [ -n "${VARDIR:=/var/lib/shorewall}" ] + [ -n "${VARDIR:=/var/lib/shorewall-lite}" ] TEMPFILE DISABLE_IPV6="" MODULESDIR="" @@ -2035,7 +2035,7 @@ cat >&3 << __EOF__ # -# Generated by Shorewall 4.5.7 - Sun Sep 2 07:05:27 2012 +# Generated by Shorewall 4.5.7 - Sun Sep 2 07:06:17 2012 # *raw :PREROUTING ACCEPT [0:0] @@ -2502,7 +2502,7 @@ $command <<__EOF__ # -# Generated by Shorewall 4.5.7 - Sun Sep 2 07:05:27 2012 +# Generated by Shorewall 4.5.7 - Sun Sep 2 07:06:17 2012 # *raw :PREROUTING ACCEPT [0:0] Here''s the shorewallrc file: # # Created by Shorewall Core version 4.5.6-Beta3 configure.pl - Jun 21 2012 11:26:48 # HOST=debian PREFIX=/usr SHAREDIR=${PREFIX}/share LIBEXECDIR=${PREFIX}/share PERLLIBDIR=${PREFIX}/share/shorewall CONFDIR=/etc SBINDIR=/sbin MANDIR=${PREFIX}/share/man INITDIR=/etc/init.d INITSOURCE=init.debian.sh INITFILE=$PRODUCT AUXINITSOURCEAUXINITFILESYSTEMDSYSCONFFILE=default.debian SYSCONFDIR=/etc/default SPARSE=Yes ANNOTATEDVARDIR=/var/lib As you can see, in both cases, VARDIR is set using the directory from shorewallrc and the product as the basename. You do have a copy of the firewall''s shorewallrc file in it''s configuration directory, right?>> >> >>> Patch RTSTOPPED.patch attached. >> Will look into it when I have the time. >> >>> >>>> 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>. >> Quite right, but the "modprobe" command I was using was a bloody >> busybox abomination and that was executing simply because shorewall >> was assuming (or, rather, hard-coding) pre-defined paths, like >> /sbin and /bin.The PATH variable is set in the same area as the differences shown above. It is set from the value in the .conf.>> >> If shorewall was honouring the path variables as I specified in my >> shorewall.conf file, it would have executed *my* version of >> modprobe (which, incidentally, was in /opt/sbin and compiled >> *specifically* to look for kernel modules in >> /opt/lib/modules/<kernel-version>, together with the correct >> modules.dep), thus avoiding the problem I described above. >>Which could have been accomplished using the MODULESDIR option in shorewall.conf.>>> Done. >> Thanks. >> >>> 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. >> This is precisely what I have done. I initially "trusted" this >> option, though, decided to check and see what the effect of >> deploying it is and I am glad I did, because I realised what was >> happening. >> >>> I will add a warning in the manpages. >> I am not sure that would be enough. You are opening a pinhole in >> the firewall and warning users about it. There are quite a few >> gullible individuals out there who either won''t pay attention to >> this warning or worse. My advice would be to either remove it >> completely or allow it to be specified with parameters (similar to >> "nets", i.e. dhcp=255.255.255.255,10.1.1.17). >>Okay -- I''ll add it to my todo list.>>>> >>>> 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? >> I''ll prepare a test case when I have more time.Thanks.>> >>>> 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. >> Separate entries for what? As it stands, all 6 conditionals are >> collapsed into two equal set of statements. I don''t see a problem >> of going a step further and collapsing them all into one.The Fedora Shorewall maintainer is subscribed to the list; I''ll let him decide.>> >>> I really should deprecate the ''try'' command as it duplicates the >>> functionality of the ''safe-start'' and ''safe-restart'' commands. >> Are they the same? What I like about "try" is that it starts the >> firewall regardless of the state it was in (perfect when I don''t >> care what that state was). Can I achieve the same with safe-start >> then?You can achieve the same thing with safe-restart and with just plain restart.>>> 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?>>>> OK, let me explain my use case. >> >> On one of my machines I have 7 interfaces, 2 of which *must* be up >> when the system is brought alive (one uses dhcp to obtain its >> lease, the other is a vpn to a different location), the rest of the >> interfaces are brought up in the standard way (ifup). >> >> For security and performance reasons, I have the whole disk image >> loaded into ram, with the exception of the security auditing >> daemon, SELinux, syslog-ng logs and some non-essential system >> settings, which survive the reboot. The rest is completely lost. >> The whole root (/) is completely locked and even though changes are >> "made" to all files, none of these survive the reboot with the >> exceptions I just mentioned. >> >> So, in order to "lock" my firewall *before* the 2 interfaces (or >> anything else) are brought up, what I currently do is compile my >> shorewall script (shorewall compile), then execute shorewall-init, >> then bring up the 2 interfaces, bring the rest of the network up >> and finally start shorewall. >> >> This is done so that between the time the 2 interfaces are brought >> up (and my firewall is completely open) and the rest of the network >> starts, I would like everything to be locked out and only the >> essential stuff to be let in. >> >> The second reason to do this (which I can''t implement at present >> since the integration with ifup/ifdown and shorewall-init seems >> unworkable) is if any of the 2 interfaces changes its status (goes >> down, changes its IP address etc), I have to repeat the above steps >> and secure the firewall first until either these interfaces sort >> themselves out, or, someone logs in (via ssh) to clear the mess.Okay -- for Shorewall and Shorewall6, I can compile the script if it doesn''t exist. -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
> + g_confdir=/etc/shorewall-lite > + g_product="Shorewall Lite" > + g_program=shorewall-lite > + g_basedir=/usr/share/shorewall-lite > + CONFIG_PATH="/etc/shorewall-lite:/usr/share/shorewall-lite" > + [ -n "${VARDIR:=/var/lib/shorewall-lite}" ]Exactly! Why is g_confdir hard-coded and not set as ${CONFDIR}/shorewall-lite? Why is g_basedir also hard-coded and not set as ${SHAREDIR}/shorewall-lite? Finally, since VARDIR is not set yet, it would also be hard-coded to /var/lib/shorewall-lite. This is what I have in my "compile" make target for shorewall-lite: # Contains one hell of an ugly hack! compile: @echo "Compiling shorewall and building ''$(FIREWALL_FILE)'' and ''$(FIREWALL_CONFIG_FILE)''" @shorewall compile -T -p -e . $(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME) @sed -i "s:g_family=4:g_family=4\n\t. $(SHOREWALLRC):" $(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME) @sed -i "s:g_confdir=/etc/shorewall-lite:g_confdir=\$${CONFDIR}/shorewall-lite:" $(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME) @sed -i "s:g_basedir=/usr/share/shorewall-lite:g_basedir=\$${SHAREDIR}/shorewall-lite:" $(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME) @sed -i "s/CONFIG_PATH=\"\/etc\/shorewall-lite:\/usr\/share\/shorewall-lite\"//" $(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME) As you can see from the above, I source shorewallrc first and then set the appropriate directories. This isn''t done in shorewall-lite''s "firewall" script, at least not in version 4.5.6 which is what I am using.> The PATH variable is set in the same area as the differences shown > above. It is set from the value in the .conf.lib.cli:3106: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin> >>> If shorewall was honouring the path variables as I specified in my >>> shorewall.conf file, it would have executed *my* version of >>> modprobe (which, incidentally, was in /opt/sbin and compiled >>> *specifically* to look for kernel modules in >>> /opt/lib/modules/<kernel-version>, together with the correct >>> modules.dep), thus avoiding the problem I described above. >>> > > Which could have been accomplished using the MODULESDIR option in > shorewall.conf.Except that it won''t. It would have executed the busybox modprobe with my own (new) kernel modules directory, which would also fail. I want to execute *my* modprobe with *my* kernel modules directory. WHen the PATH is hard-coded it is hard to do that.>>>> I really should deprecate the ''try'' command as it duplicates the >>>> functionality of the ''safe-start'' and ''safe-restart'' commands. >>> Are they the same? What I like about "try" is that it starts the >>> firewall regardless of the state it was in (perfect when I don''t >>> care what that state was). Can I achieve the same with safe-start >>> then? > > You can achieve the same thing with safe-restart and with just plain > restart.So, restart will start shorewall even if it has not been started? That''s good if so.> >>> OK, let me explain my use case. > > Okay -- for Shorewall and Shorewall6, I can compile the script if it > doesn''t exist.You mean shorewall-init? Please explain. ------------------------------------------------------------------------------ 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/
On 09/02/2012 08:06 AM, Mr Dash Four wrote:>> + g_confdir=/etc/shorewall-lite >> + g_product="Shorewall Lite" >> + g_program=shorewall-lite >> + g_basedir=/usr/share/shorewall-lite >> + CONFIG_PATH="/etc/shorewall-lite:/usr/share/shorewall-lite" >> + [ -n "${VARDIR:=/var/lib/shorewall-lite}" ] > Exactly! > > Why is g_confdir hard-coded and not set as ${CONFDIR}/shorewall-lite? Why is g_basedir also hard-coded and not set as ${SHAREDIR}/shorewall-lite? Finally, since VARDIR is not set yet, it would also be hard-coded to /var/lib/shorewall-lite. >THEY ARE NOT HARD-CODED -- They come from the first ''shorewallrc'' file encountered on your CONFIG_PATH at the time of compilation.> This is what I have in my "compile" make target for shorewall-lite: > > # Contains one hell of an ugly hack! > compile: > @echo "Compiling shorewall and building ''$(FIREWALL_FILE)'' and ''$(FIREWALL_CONFIG_FILE)''" > @shorewall compile -T -p -e . $(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME) > @sed -i "s:g_family=4:g_family=4\n\t. $(SHOREWALLRC):" $(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME) > @sed -i "s:g_confdir=/etc/shorewall-lite:g_confdir=\$${CONFDIR}/shorewall-lite:" $(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME) > @sed -i "s:g_basedir=/usr/share/shorewall-lite:g_basedir=\$${SHAREDIR}/shorewall-lite:" $(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME) > @sed -i "s/CONFIG_PATH=\"\/etc\/shorewall-lite:\/usr\/share\/shorewall-lite\"//" $(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME) > > As you can see from the above, I source shorewallrc first and then set the appropriate directories. This isn''t done in shorewall-lite''s "firewall" script, at least not in version 4.5.6 which is what I am using. > > >> The PATH variable is set in the same area as the differences shown >> above. It is set from the value in the .conf. > lib.cli:3106: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin >That''s the default if PATH isn''t set in your ${CONFDIR}/${g_product}.conf file. And the compiled script doesn''t use lib.cli.>> >>>> If shorewall was honouring the path variables as I specified in my >>>> shorewall.conf file, it would have executed *my* version of >>>> modprobe (which, incidentally, was in /opt/sbin and compiled >>>> *specifically* to look for kernel modules in >>>> /opt/lib/modules/<kernel-version>, together with the correct >>>> modules.dep), thus avoiding the problem I described above. >>>> >> >> Which could have been accomplished using the MODULESDIR option in >> shorewall.conf. > Except that it won''t. It would have executed the busybox modprobe with my own (new) kernel modules directory, which would also fail. I want to execute *my* modprobe with *my* kernel modules directory. WHen the PATH is hard-coded it is hard to do that. >How have you set PATH in ${CONFDIR}/shorewall-lite/shorewall-lite.conf?>> You can achieve the same thing with safe-restart and with just plain >> restart. > So, restart will start shorewall even if it has not been started? That''s good if so. >Yes.>> >>>> OK, let me explain my use case. >> >> Okay -- for Shorewall and Shorewall6, I can compile the script if it >> doesn''t exist. > You mean shorewall-init? Please explain.Yes -- in the shorewall-init init scripts. -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
On 09/02/2012 08:44 AM, Tom Eastep wrote:> On 09/02/2012 08:06 AM, Mr Dash Four wrote: >>> + g_confdir=/etc/shorewall-lite >>> + g_product="Shorewall Lite" >>> + g_program=shorewall-lite >>> + g_basedir=/usr/share/shorewall-lite >>> + CONFIG_PATH="/etc/shorewall-lite:/usr/share/shorewall-lite" >>> + [ -n "${VARDIR:=/var/lib/shorewall-lite}" ] >> Exactly! >> >> Why is g_confdir hard-coded and not set as ${CONFDIR}/shorewall-lite? Why is g_basedir also hard-coded and not set as ${SHAREDIR}/shorewall-lite? Finally, since VARDIR is not set yet, it would also be hard-coded to /var/lib/shorewall-lite. >> > > THEY ARE NOT HARD-CODED -- They come from the first ''shorewallrc'' file > encountered on your CONFIG_PATH at the time of compilation.And when you specify a configuration directory on the command line, the configuration directory becomes the first directory in $CONFIG_PATH. -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
On 09/02/2012 08:06 AM, Mr Dash Four wrote:>> The PATH variable is set in the same area as the differences shown >> above. It is set from the value in the .conf. > lib.cli:3106: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin >When you compile with -e, in addition to ''firewall'', the compiler also generates ''firewall.conf''. This is expected to be installed in ${VARDIR}/shorewall-lite/. In lib.cli below 3106: [ -f ${VARDIR}/firewall.conf ] && . ${VARDIR}/firewall.conf [ -n "$PATH" ] || \ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
> THEY ARE NOT HARD-CODED -- They come from the first ''shorewallrc'' file > encountered on your CONFIG_PATH at the time of compilation.Ah, right, which is also wrong as they should come from the remote copy of shorewallrc. I presume that is fixed in your (CONF.patch?) patch, right? I also forgot to mention the different meaning of VARDIR in shorewall and shorewall-lite. In the former, this is assumed to be /var/lib, in the latter it is /var/lib/shorewall-lite, but I suspect you already know that.>> lib.cli:3106: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin >> > > That''s the default if PATH isn''t set in your > ${CONFDIR}/${g_product}.conf file. And the compiled script doesn''t use > lib.cli.I did a little experiment when discovered this bug and explicitly wrote the existing path just before modprobe was executed. It wasn''t like what I have specified in my .conf file at all, hence the error I was getting. I had to alter the file in order to get it to execute my own version of modprobe with the required modules.>> Except that it won''t. It would have executed the busybox modprobe with my own (new) kernel modules directory, which would also fail. I want to execute *my* modprobe with *my* kernel modules directory. WHen the PATH is hard-coded it is hard to do that. >> > > How have you set PATH in ${CONFDIR}/shorewall-lite/shorewall-lite.conf?CONFIG_PATH="/opt/etc/shorewall:/opt/share/shorewall:/etc/shorewall:/usr/share/shorewall" ------------------------------------------------------------------------------ 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/
> In lib.cli below 3106: > > [ -f ${VARDIR}/firewall.conf ] && . ${VARDIR}/firewall.conf > > [ -n "$PATH" ] || \ > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbinIn my version of shorewall this is as: if [ $# -eq 0 ]; then usage 1 fi PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin MUTEX_TIMEOUT [ -f ${g_confdir}/vardir ] && . ${g_confdir}/vardir As you can see, it is unconditionally hard-coded. ------------------------------------------------------------------------------ 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/
On 09/02/2012 09:31 AM, Mr Dash Four wrote:>> THEY ARE NOT HARD-CODED -- They come from the first ''shorewallrc'' file >> encountered on your CONFIG_PATH at the time of compilation. > Ah, right, which is also wrong as they should come from the remote copy of shorewallrc. I presume that is fixed in your (CONF.patch?) patch, right?No -- the configuration directory is expected to contain the remote firewall''s shorewallrc file. This point was not previously explained in the Shorewall-Lite article :-( It is now.> > I also forgot to mention the different meaning of VARDIR in shorewall and shorewall-lite. In the former, this is assumed to be /var/lib, in the latter it is /var/lib/shorewall-lite, but I suspect you already know that.It''s not! The meaning of VARDIR is exactly the same. Here''s the history: - Originally, each of the products had their own CLI and libraries. It was a maintenance nightmare. Shorewall6 never had the same features as Shorewall and the -Lite products were always different from their full-featured counterparts. - In all of these programs and libraries, VARDIR pointed to /var/lib/$product. - I finally bit the bullet and unified all of the code. I retained the the meaning of VARDIR. - When I created the ''shorewallrc'' file, I had to make a decision about what to do with /var/lib; I could call it VARDIR or something else. I chose to retain the name VARDIR and have each product append the /<product name> to the VARDIR setting from shorewallrc. So there is two interpretations of VARDIR -- one in the shorewallrc file and one in the code.> > >>> lib.cli:3106: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin >>> >> >> That''s the default if PATH isn''t set in your >> ${CONFDIR}/${g_product}.conf file. And the compiled script doesn''t use >> lib.cli. > I did a little experiment when discovered this bug and explicitly wrote the existing path just before modprobe was executed. It wasn''t like what I have specified in my .conf file at all, hence the error I was getting. I had to alter the file in order to get it to execute my own version of modprobe with the required modules. > >>> Except that it won''t. It would have executed the busybox modprobe with my own (new) kernel modules directory, which would also fail. I want to execute *my* modprobe with *my* kernel modules directory. WHen the PATH is hard-coded it is hard to do that. >>> >> >> How have you set PATH in ${CONFDIR}/shorewall-lite/shorewall-lite.conf? > CONFIG_PATH="/opt/etc/shorewall:/opt/share/shorewall:/etc/shorewall:/usr/share/shorewall"Have you installed the firewall.conf file? What does it have for a PATH setting? What is the PATH setting in the initialize() function of the generated script? -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
On 09/02/2012 09:32 AM, Mr Dash Four wrote:>> In lib.cli below 3106: >> >> [ -f ${VARDIR}/firewall.conf ] && . ${VARDIR}/firewall.conf >> >> [ -n "$PATH" ] || \ >> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin > In my version of shorewall this is as: > > if [ $# -eq 0 ]; then > usage 1 > fi > > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin > MUTEX_TIMEOUT> > [ -f ${g_confdir}/vardir ] && . ${g_confdir}/vardir > > > As you can see, it is unconditionally hard-coded.Okay -- you can patch it as I described in my earlier email. But that still doesn''t explain why loading modules from the generated script failed. -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
> So there is two interpretations of VARDIR -- one in the shorewallrc file > and one in the code.In other words, VARDIR in shorewallrc is different from VARDIR everywhere else? And you don''t find that the least bit confusing?> Have you installed the firewall.conf file? What does it have for a PATH > setting?# # Shorewall auxiliary configuration file created by Shorewall version 4.5.6 - Sun Sep 2 15:35:15 2012 # [ -n "${PATH:=/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin}" ]> What is the PATH setting in the initialize() function of the > generated script?PATH="/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin" ------------------------------------------------------------------------------ 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/
> Okay -- you can patch it as I described in my earlier email. But that > still doesn''t explain why loading modules from the generated script failed.Already done. I''ll diff the entire directory where various shorewall library files are installed in my /opt/shorewall tree. I vaguely remember that I had to make some modifications to make it work, but don''t know what were these, so when I run a diff against a "pristine" shorewall-lite version I am hoping to find out. So lets leave it there for the time being. ------------------------------------------------------------------------------ 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/
On 9/2/12 9:52 AM, Mr Dash Four wrote:>> So there is two interpretations of VARDIR -- one in the shorewallrc file >> and one in the code. > In other words, VARDIR in shorewallrc is different from VARDIR everywhere else? And you don''t find that the least bit confusing? >It is confusing when discussing internals. I''ll change the code someday to use a different variable name. -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
>> In other words, VARDIR in shorewallrc is different from VARDIR everywhere else? And you don''t find that the least bit confusing? >> > > It is confusing when discussing internals. I''ll change the code someday > to use a different variable name. >You can introduce VARLIB (new variable) in shorewallrc to point to "/var/lib" and in the same shorewallrc file to change the existing VARDIR to point to ${VARLIB}/$PRODUCT. That way, there is no confusion as to the meaning of these two variables and when I source shorewallrc I know exactly what I am getting. As it stands though, when I am debugging the code produced by any shorewall product and come across VARDIR, I don''t know what the hell is that: is it ${VARDIR}/$product or is just the original $VARDIR from shorewallrc. ------------------------------------------------------------------------------ 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/
On 09/02/2012 10:33 AM, Mr Dash Four wrote:> >>> In other words, VARDIR in shorewallrc is different from VARDIR everywhere else? And you don''t find that the least bit confusing? >>> >> >> It is confusing when discussing internals. I''ll change the code someday >> to use a different variable name. >> > You can introduce VARLIB (new variable) in shorewallrc to point to > "/var/lib" and in the same shorewallrc file to change the existing > VARDIR to point to ${VARLIB}/$PRODUCT. That way, there is no confusion > as to the meaning of these two variables and when I source shorewallrc I > know exactly what I am getting. > > As it stands though, when I am debugging the code produced by any > shorewall product and come across VARDIR, I don''t know what the hell is > that: is it ${VARDIR}/$product or is just the original $VARDIR from > shorewallrc. >Thanks -- I''ve been thinking along the same lines. -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
> Patch CONF.patch attached.[me@test1 dmz]$ shorewall compile -T -p -e Compiling... ERROR: Ordinary users may not compile the /etc/shorewall configuration Terminated [me@test1 dmz]$ shorewall compile -T -p -e . ERROR: . is a directory [me@test1 dmz]$ shorewall compile -T -p -e . firewall Compiling... Processing /home/me/shorewall/dmz/params ... Processing /home/me/shorewall/dmz/shorewall.conf... Compiling /home/me/shorewall/dmz/zones... Compiling /home/me/shorewall/dmz/interfaces... Determining Hosts in Zones... Locating Action Files... Compiling /home/me/shorewall/dmz/action.Drop for chain Drop... Compiling /home/me/shorewall/dmz/action.Reject for chain Reject... Compiling /home/me/shorewall/dmz/policy... Compiling /home/me/shorewall/dmz/notrack... ERROR: Unable to open /opt/share/shorewall//lib.core: No such file or directory at /usr/share/perl5/Shorewall/Config.pm line 970 Shorewall::Config::fatal_error(''Unable to open /opt/share/shorewall//lib.core: No such file o...'') called at /usr/share/perl5/Shorewall/Config.pm line 1803 Shorewall::Config::copy(''/opt/share/shorewall//lib.core'') called at /usr/share/perl5/Shorewall/Compiler.pm line 92 Shorewall::Compiler::generate_script_1(''firewall'') called at /usr/share/perl5/Shorewall/Compiler.pm line 680 Shorewall::Compiler::compiler(''script'', ''firewall'', ''directory'', ''/home/me/shorewall/dmz'', ''verbosity'', 1, ''timestamp'', 0, ''debug'', ...) called at /usr/libexec/shorewall/compiler.pl line 134 lib.core is copied into my current directory. My CONFIG_PATH is CONFIG_PATH=".:/opt/etc/shorewall:/opt/share/shorewall:/etc/shorewall:/usr/share/shorewall" (on a separate note, I think I should not have to include "." in that path - this should be assumed automatically by shorewall, I think, as I am compiling for a remote system).> Patch RTSTOPPED.patch attached.OK, there is a bit of a problem which I haven''t accounted for... Suppose I have this: routestopped ~~~~~~~~~~~~ eth0 +mickey-mouse-net source This produces mickey-mouse-net src in INPUT as well as FORWARD. OUTPUT is untouched (nothing is there). When I have this: eth0 +mickey-mouse-net dest This produces mickey-mouse-net src in INPUT, mickey-mouse-net dst in FORWARD and mickey-mouse-net dst in OUTPUT (I am not sure about that!). Things get a bit more hairy when I use multi-dimensional sets: eth0 +mickey-mouse-net[dst,dst] dest Gets me this: ERROR: Unknown Host (dst]) /home/me/shorewall/dmz/routestopped (line 16) at /usr/share/perl5/Shorewall/Config.pm line 970 Shorewall::Config::fatal_error(''Unknown Host (dst])'') called at /usr/share/perl5/Shorewall/IPAddrs.pm line 157 Shorewall::IPAddrs::validate_4address(''dst]'', 1) called at /usr/share/perl5/Shorewall/IPAddrs.pm line 220 Shorewall::IPAddrs::validate_4net(''dst]'', 1) called at /usr/share/perl5/Shorewall/IPAddrs.pm line 780 Shorewall::IPAddrs::validate_net(''dst]'', 1) called at /usr/share/perl5/Shorewall/Chains.pm line 4886 Shorewall::Chains::imatch_source_net(''dst]'') called at /usr/share/perl5/Shorewall/Misc.pm line 577 Shorewall::Misc::process_routestopped() called at /usr/share/perl5/Shorewall/Misc.pm line 2356 Shorewall::Misc::compile_stop_firewall(0, 1) called at /usr/share/perl5/Shorewall/Compiler.pm line 848 Shorewall::Compiler::compiler(''script'', ''firewall'', ''directory'', ''/home/me/shorewall/dmz'', ''verbosity'', 2, ''timestamp'', 0, ''debug'', ...) called at /usr/libexec/shorewall/compiler.pl line 134 I have to say, I am not sure how this is going to be dealt with though. If I were you, I would scrap this source/dest malarkey and have a straight definitions as I currently use in the rules file (or blrules). Let the user decide in what direction what rules should exist. WHen ipsets are used, there are quite a few possible nasty twists, like "+[set1[dst,src],set2[src,dst]]" - you get my drift. So, if you are going to support ipsets in rulestopped, then I''d suggest to scrap the existing format and use the exiting one from etiher rules or blrules. Any better ideas?>> 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?This has to wait a bit longer though. I''ll get on it in a day or two. ------------------------------------------------------------------------------ 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/
>>> 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. > > Patch attached.Yep, that now works as expected. ------------------------------------------------------------------------------ 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/
On 09/02/2012 06:34 PM, Mr Dash Four wrote:> >> Patch CONF.patch attached. > [me@test1 dmz]$ shorewall compile -T -p -e > Compiling... > ERROR: Ordinary users may not compile the /etc/shorewall configuration > Terminated > [me@test1 dmz]$ shorewall compile -T -p -e . > ERROR: . is a directory > [me@test1 dmz]$ shorewall compile -T -p -e . firewall > Compiling... > Processing /home/me/shorewall/dmz/params ... > Processing /home/me/shorewall/dmz/shorewall.conf... > Compiling /home/me/shorewall/dmz/zones... > Compiling /home/me/shorewall/dmz/interfaces... > Determining Hosts in Zones... > Locating Action Files... > Compiling /home/me/shorewall/dmz/action.Drop for chain Drop... > Compiling /home/me/shorewall/dmz/action.Reject for chain Reject... > Compiling /home/me/shorewall/dmz/policy... > Compiling /home/me/shorewall/dmz/notrack... > ERROR: Unable to open /opt/share/shorewall//lib.core: No such file or directory at /usr/share/perl5/Shorewall/Config.pm line 970 > Shorewall::Config::fatal_error(''Unable to open /opt/share/shorewall//lib.core: No such file o...'') called at /usr/share/perl5/Shorewall/Config.pm line 1803 > Shorewall::Config::copy(''/opt/share/shorewall//lib.core'') called at /usr/share/perl5/Shorewall/Compiler.pm line 92 > Shorewall::Compiler::generate_script_1(''firewall'') called at /usr/share/perl5/Shorewall/Compiler.pm line 680 > Shorewall::Compiler::compiler(''script'', ''firewall'', ''directory'', ''/home/me/shorewall/dmz'', ''verbosity'', 1, ''timestamp'', 0, ''debug'', ...) called at /usr/libexec/shorewall/compiler.pl line 134 > > lib.core is copied into my current directory. My CONFIG_PATH is CONFIG_PATH=".:/opt/etc/shorewall:/opt/share/shorewall:/etc/shorewall:/usr/share/shorewall" (on a separate note, I think I should not have to include "." in that path - this should be assumed automatically by shorewall, I think, as I am compiling for a remote system). >lib.core isn''t a configuration file; it is part of the Shorewall installation. The compiler therefore doesn''t use CONFIG_PATH but rather assumes that it will be installed in ${SHAREDIR}/shorewall. I agree about including "."; it is already included when using the ''load'', ''reload'' and ''export'' commands.>> Patch RTSTOPPED.patch attached. > > OK, there is a bit of a problem which I haven''t accounted for... > > Suppose I have this: > > routestopped > ~~~~~~~~~~~~ > eth0 +mickey-mouse-net source > > This produces mickey-mouse-net src in INPUT as well as FORWARD. OUTPUT is untouched (nothing is there). > > When I have this: > > eth0 +mickey-mouse-net dest > > This produces mickey-mouse-net src in INPUT, mickey-mouse-net dst in FORWARD and mickey-mouse-net dst in OUTPUT (I am not sure about that!). > > Things get a bit more hairy when I use multi-dimensional sets: > > eth0 +mickey-mouse-net[dst,dst] dest > > Gets me this: > > ERROR: Unknown Host (dst]) /home/me/shorewall/dmz/routestopped (line 16) at /usr/share/perl5/Shorewall/Config.pm line 970 > Shorewall::Config::fatal_error(''Unknown Host (dst])'') called at /usr/share/perl5/Shorewall/IPAddrs.pm line 157 > Shorewall::IPAddrs::validate_4address(''dst]'', 1) called at /usr/share/perl5/Shorewall/IPAddrs.pm line 220 > Shorewall::IPAddrs::validate_4net(''dst]'', 1) called at /usr/share/perl5/Shorewall/IPAddrs.pm line 780 > Shorewall::IPAddrs::validate_net(''dst]'', 1) called at /usr/share/perl5/Shorewall/Chains.pm line 4886 > Shorewall::Chains::imatch_source_net(''dst]'') called at /usr/share/perl5/Shorewall/Misc.pm line 577 > Shorewall::Misc::process_routestopped() called at /usr/share/perl5/Shorewall/Misc.pm line 2356 > Shorewall::Misc::compile_stop_firewall(0, 1) called at /usr/share/perl5/Shorewall/Compiler.pm line 848 > Shorewall::Compiler::compiler(''script'', ''firewall'', ''directory'', ''/home/me/shorewall/dmz'', ''verbosity'', 2, ''timestamp'', 0, ''debug'', ...) called at /usr/libexec/shorewall/compiler.pl line 134 > > I have to say, I am not sure how this is going to be dealt with though. If I were you, I would scrap this source/dest malarkey and have a straight definitions as I currently use in the rules file (or blrules). Let the user decide in what direction what rules should exist. WHen ipsets are used, there are quite a few possible nasty twists, like "+[set1[dst,src],set2[src,dst]]" - you get my drift. So, if you are going to support ipsets in rulestopped, then I''d suggest to scrap the existing format and use the exiting one from etiher rules or blrules. Any better ideas? >Yes -- looks like we need a FORMAT 2 routestopped file in order to handle multi-dimensional sets. -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
On 2 September 2012 15:25, Tom Eastep <teastep@shorewall.net> wrote:> On 09/02/2012 07:04 AM, Tom Eastep wrote: >> On 09/01/2012 07:29 PM, Mr Dash Four wrote: >>>>> 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. >>> Separate entries for what? As it stands, all 6 conditionals are >>> collapsed into two equal set of statements. I don''t see a problem >>> of going a step further and collapsing them all into one. > > The Fedora Shorewall maintainer is subscribed to the list; I''ll let him > decide. >While the suggestion is technically correct, it''s simply a cosmetic fix - I think it''s best just to leave it alone - after all, nothing is broken. Also init scripts are now legacy on Fedora systems anyway. Jonathan. ------------------------------------------------------------------------------ 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/
> lib.core isn''t a configuration file; it is part of the Shorewall > installation. The compiler therefore doesn''t use CONFIG_PATH but rather > assumes that it will be installed in ${SHAREDIR}/shorewall. >True, and I presume since the remote shorewallrc is used, this throws the compiler off as no such file exists on the HOST system. Hmm, interesting this... Can shorewall load (and use) the HOST shorewallrc for the "core libraries" (the ones needed for compilation for producing firewall and firewall.conf for remote system) and use the remote shorewallrc for everything else? Would that be possible? The idea is that if the core libraries on the host are going to be used, than it makes sense for them to adopt the host shorewallrc file, while the compiler uses the remote version of shorewallrc for building firewall and firewall.conf. I presume apart from the lib.* files and the shorewall executable, along with getparams and various perl libraries there isn''t much else.> Yes -- looks like we need a FORMAT 2 routestopped file in order to > handle multi-dimensional sets. >I was thinking more along the lines of the approach you adopted with "blacklist" and "blrules" files, which I quite liked - use a new file (say, "rulestopped") along the old routestopped (without ipset support) and after a while (a couple of revisions), you deprecate the old routestopped in favour of rulestopped where you can grant full ipsets support. That way you don''t have to touch the existing routestopped at all and start afresh with the new rulestopped. ------------------------------------------------------------------------------ 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/
On 9/3/12 7:13 AM, Mr Dash Four wrote:> >> lib.core isn''t a configuration file; it is part of the Shorewall >> installation. The compiler therefore doesn''t use CONFIG_PATH but rather >> assumes that it will be installed in ${SHAREDIR}/shorewall. >> > True, and I presume since the remote shorewallrc is used, this throws > the compiler off as no such file exists on the HOST system. Hmm, > interesting this... > > Can shorewall load (and use) the HOST shorewallrc for the "core > libraries" (the ones needed for compilation for producing firewall and > firewall.conf for remote system) and use the remote shorewallrc for > everything else? Would that be possible? The idea is that if the core > libraries on the host are going to be used, than it makes sense for them > to adopt the host shorewallrc file, while the compiler uses the remote > version of shorewallrc for building firewall and firewall.conf. > > I presume apart from the lib.* files and the shorewall executable, along > with getparams and various perl libraries there isn''t much else.I''ve implemented code that works around this along with a new ''stoppedrules'' file. I haven''t finished the manpages for the latter, but when I do finish them, do you want me to send you early copies of the Shorewall-core, Shorewall and Shorewall-lite tarballs? -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 \________________________________________________ ------------------------------------------------------------------------------ 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/
> I''ve implemented code that works around this along with a new > ''stoppedrules'' file. > > I haven''t finished the manpages for the latter, but when I do finish > them, do you want me to send you early copies of the Shorewall-core, > Shorewall and Shorewall-lite tarballs? >Please do. As always, I am a willing tester, particularly where I''ve reported the bugs/requested the new features, so yes, count me in, though with the standard caveat of "time-permitting". I might also send you something else I came across recently, which I already implemented on all my systems here and which I think shorewall could benefit greatly, but that''s for another day... ------------------------------------------------------------------------------ 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/
> 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!Since upgrading to 4.5.8-Beta1, I am unable to reproduce this (with the same shorewall configuration), so I presume whatever it was that was causing this, it has now been fixed. ------------------------------------------------------------------------------ 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/