Hello, everyone. First, the vitals: Shorewall version 4.0.9, iptables 1.4.0 on kernel 2.6.24.7 (from mandriva 2008.1). My firewall configuration is running properly. The only nuisance is in something I had to do while configuring sub-zones that I feel I shouldn''t have had to do. Clearly this is me being dumber than usual, but I''d like some input on the matter. We have 3 sites - call them A, B and C. They all form a triangle using Racoon IPSec (i.e. A<->B, B<->C, C<->A). There''s NO weird routing through sites for redundancy - if you don''t have direct access, you''re SOL basically. Each site runs a linux firewall (yipee!!), with shorewall on it. Each site is configured pretty much the same. 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 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 net $NET detect # end hosts: # begin BIG $LAN:$LAN_IP BIG $NET:$B_IP ,ipsec BIG $NET:$C_IP ,ipsec site_b $NET:$B_IP site_c $NET:$C_IP # 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 site_c $NET:$C_IP # end I.e.: not having to *explicitly* add the host declarations to the actual "BIG" zone and have that zone include all subzones. IMPLICIT_CONTINUE is set to "Yes" in the shorewall.conf file. I did have to add policies to permit traffic between the sub-zones explicitly (i.e. lan<->c, lan<->b), but that much I did expect and I feel it''s correct to have had to do that. I probably have the nesting stuff bass-ackwards (wouldn''t be the first time!), but I''d like some input here on whether I''m off base, or what I missed. I did read the docs and didn''t find my exact answer on them... Thanks for any help! -- 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: diego.rivera@rbxglobal.com | 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
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 > # endDiego, 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 -- 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 \________________________________________________ ------------------------------------------------------------------------------ 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
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 net $NET detect # end hosts: # begin BIG $LAN:$LAN_IP BIG $NET:$B_IP ,ipsec BIG $NET:$C_IP ,ipsec site_b $NET:$B_IP site_c $NET:$C_IP # 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 site_c $NET:$C_IP # 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: diego.rivera@rbxglobal.com | 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
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 net $NET detect # end hosts: # begin BIG $LAN:$LAN_IP BIG $NET:$B_IP ,ipsec BIG $NET:$C_IP ,ipsec site_b $NET:$B_IP site_c $NET:$C_IP # 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 site_c $NET:$C_IP # 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: diego.rivera@rbxglobal.com | 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 Shorewall-users@lists.sourceforge.net 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: diego.rivera@rbxglobal.com | 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
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 -- 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 \________________________________________________ ------------------------------------------------------------------------------ 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
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
Shorewall-users@lists.sourceforge.net
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: diego.rivera@rbxglobal.com
| 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
Diego Rivera wrote:> 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. >It is actually a rather trivial change to detect the case where an IPSEC zone is nested within an IP zone (ipv4 or ipv6) and set the option automatically. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
Tom Eastep wrote:> Diego Rivera wrote: >> 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. >> > > It is actually a rather trivial change to detect the case where an IPSEC > zone is nested within an IP zone (ipv4 or ipv6) and set the option > automatically. >That change will be included in 4.4.0 RC2. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
Wow. That was easy. :) Thanks! Tom Eastep wrote: Tom Eastep wrote: Diego Rivera wrote: 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. It is actually a rather trivial change to detect the case where an IPSEC zone is nested within an IP zone (ipv4 or ipv6) and set the option automatically. That change will be included in 4.4.0 RC2. -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: diego.rivera@rbxglobal.com | 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