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