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