Though, I do have another question:

Suppose that you add logic such that rules are automatically added to "inherit" the parent zone's actions.  For instance:

SSH/ACCEPT site_a tgt
FTP/ACCEPT  BIG tgt

One way to achieve what I suggest (i.e. implicit inclusion of child zones into parent zones) would be the addition of a jump to the parent zone's chains as appropriate.  For instance, the rules for size_a->tgt traffic would be (for example):

...
-A site_a2tgt -p tcp -m tcp --dport 22 -j ACCEPT
-A site_a2tgt -j BIG2tgt   <---- New rule added to achieve "inheritance effect"
...
-A BIG2tgt -p tcp -m tcp --dport 21 -j ACCEPT
...

For sub-zones with multiple parents, the order of declaration of parents could decide which parent rule gets jumped to first, for example (i.e. leftmost parents get jumped to first).

This, of course, is based on the concept that the code to sort traffic into zones is wholly separate from the code to permit traffic between zones (which I believe is already the case).  In this scenario what I propose is a (configurable?) implicit jump from the sub-zone's rules going to target "tgt" to the parent zone's rules going to the same target when no other rule matches.  This would allow both micro and macro management of those zone rules.

Does the above make sense?  Has it already been considered and rejected? If so, can you offer references for my education?

Cheers!


Diego Rivera wrote:
Fair enough - I can live with this answer. Thanks, Tom!

Tom Eastep wrote:
Diego Rivera wrote:
  
My grief comes from the sub-zone definition.  I'll paint the picture
from firewall A's perspective, for simplicity, and use an abbreviated
config syntax so as to not bore you with the details:

zones:
# begin
fw ipv4
BIG ipv4
lan:BIG ipv4
site_a:BIG ipsec
site_b:BIG ipsec
net ipv4
# end
    

Diego,

The root of your problem comes in the zone definitions. The definitions
of the site_a and site_b zones is invalid, although the compiler isn't
flagging them as such. Because site_a and site_b are ipsec zones and BIG
is an ipv4 zone, site_a and site_b are NOT sub-zones of BIG. Traffic
to/from site_a and site_b must always be encrypted; traffic to/from BIG
is only encrypted if the hosts file is used to explicitly define
encrypted members.

  
The intent is to group *ALL* internal networks into the "BIG" zone so I
can treat them all as a single unit when writing rules (and going more
granular as required).  My problem is that for the above to work, I had
to explicitly declare *ALL* the hosts from lan, site_a and site_b in the
hosts file as belonging to BIG *in addition to* the declaration for the
zones themselves (except lan - that one's based on interfaces so it
wasn't declared in hosts):

interfaces:
# begin
lan $LAN detect <flags>
net $NET detect <flags>
# end

hosts:
# begin
BIG $LAN:$LAN_IP <flags>
BIG $NET:$B_IP <flags>,ipsec
BIG $NET:$C_IP <flags>,ipsec
site_b $NET:$B_IP <flags>
site_c $NET:$C_IP <flags>
# end

What I want to do is be able to have rules such as the following:

# begin rule-example
SomeMacro/ACCEPT BIG net:1.2.3.4
OtherMacro/REJECT net:5.6.7.8 BIG
# end rule-example

However, I'd like to be able to do that with my hosts file looking like so:

# begin
site_b $NET:$B_IP <flags>
site_c $NET:$C_IP <flags>
# end

I.e.: not having to *explicitly* add the host declarations to the actual
"BIG" zone and have that zone include all subzones.
    

That is not currently possible.

-Tom
  

--
Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email: [email protected] | www.rbxglobal.com
------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users

--
Diego Rivera
Director / System Operations
Roundbox Global : enterprise : technology : genius
------------------------------------------------------------------------------------------------------------------
Avenida 11 y Calle 7-9, Barrio Amón, San José, Costa Rica
tel: +1 (404) 567-5000 ext. 2147 | cel: +(506) 8393-0772 | fax: +(506) 2258-3695
email: [email protected] | www.rbxglobal.com
------------------------------------------------------------------------------------------------------------------

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to