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
AUXINITSOURCE=
AUXINITFILE=
SYSTEMD=
SYSCONFFILE=default.debian
SYSCONFDIR=/etc/default
SPARSE=Yes
ANNOTATED=
VARDIR=/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/
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
