I guess adding an attribute is an option - i.e. as long as we clearly document what it does and does not do, it might solve the problem for many users who can actually leverage them.

Let me think on this a bit on how we could go about adding rules for proper handling of target zones with parents...

Cheers.

Tom Eastep wrote:
Diego Rivera wrote:
  
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?
    

The problem is that BIG2tgt probably has a policy rule at the end of it.
So in the case of multiple parents, (e.g., site_a:BIG,BAD), we would
never get to sita_a2BAD.

The other problem that I see is that it is unclear what should happen if
both the source and dest zones have parents.

I think that the best way to handle this is to invent a new zone
attribute for ipv4 and ipv6 zones that would allow them to include any
ipsec subzones.

What happens now for ipsec:

Chain eth1_in (1 references)
 pkts bytes target     prot opt in     out     source
destination
    2   656 ACCEPT     udp  --  *      *       0.0.0.0/0
0.0.0.0/0           udp dpts:67:68
56114 4037K tcpflags   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           policy match dir in pol none
    0     0 vpn2fw     all  --  *      *       0.0.0.0/0
0.0.0.0/0           policy match dir in pol ipsec
57318 4287K loc2fw     all  --  *      *       0.0.0.0/0
0.0.0.0/0           policy match dir in pol none

If 'vpn' is a sub-zone of 'loc', the above rules don't work as you want
because the loc2fw chain is only traversed for unencrypted traffic.

If 'loc' had the new attribute, then these rules would be executed:

Chain eth1_in (1 references)
 pkts bytes target     prot opt in     out     source
destination
    2   656 ACCEPT     udp  --  *      *       0.0.0.0/0
0.0.0.0/0           udp dpts:67:68
56114 4037K tcpflags   tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           policy match dir in pol none
    0     0 vpn2fw     all  --  *      *       0.0.0.0/0
0.0.0.0/0           policy match dir in pol ipsec
57318 4287K loc2fw     all  --  *      *       0.0.0.0/0
0.0.0.0/0

That would allow things to work as you want.

-Tom
  

------------------------------------------------------------------------------ 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