Hi,
According to http://www.shorewall.net/bridge-Shorewall-perl.html:
<fw> -> <BP zone> rules are not allowed
<non-BP zone> -> <BP zone> rules are not allowed
"Policies from a non-BP zone to a BP are disallowed.
Rules where the SOURCE is a non-BP zone and the DEST is a BP zone are
disallowed."
/etc/shorewall/zones defines a <BP zone> as a "subzone" of a
<non-BP zone>:
#ZONE TYPE OPTIONS
fw firewall
elsewhere ipv4
world ipv4
net:world bport
loc:world bport
So I''m supposing that one CANNOT define rules and policies such as:
<elsewhere> -> <loc>
but can define rules such as:
<elsewhere> -> <world>
Suppose that my loc zone is physically connected to eth0 and net is connected to
eth1 and that I want to allow specific IP addr/port traffic from
<elsewhere> to <net> but block it from <elsewhere> to
<loc>.
If I set this in /etc/shorewall/policy:
elsewhere world REJECT
and this in /etc/shorewall/rules:
ACCEPT elsewhere world:<SMTP_SERVER_IP_ADDR>
tcp 25
then I should be blocking all SMTP traffic except to my SMTP server.
However, I won''t be able to explicitly allow tcp 25 traffic to the
"loc" subzone of "world" and disallow tcp 25 traffic to the
"net" subzone.
Also, if the net subzone is considered "insecure" then a host in that
subzone could assign itself the same IP address as my SMTP server thus receiving
SMTP traffic illegitimately.
Is this a physdev match limitation?
Is there a solution to this other than making sure that my net subzone
isn''t "insecure"?
On the other hand, if my /etc/shorewall/policy file contains:
net elsewhere REJECT info
net world REJECT info
and a host from <elsewhere> tries to connect to
<SMTP_SERVER_IP_ADDR> and the latter is within the net bport subzone (ie.
connected to eth1 in my example) then it should fail, right?
The connection should succeed if <SMTP_SERVER_IP_ADDR> were connected to
eth0 (loc bport subzone).
Thanks,
Vieri
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
Hello,
What does your shorewall interfaces looks like?
One question I had is which interface is the <elsewhere> zone connected
to?
Maybe <elsewhere> is better suited for an entry on shorewall host file?
Cheers
-----------------
Leandro Avila
----- Original Message -----
From:Vieri Di Paola <vieridipaola@yahoo.com>
To:shorewall-users@lists.sourceforge.net
Cc:
Sent:Thursday, March 24, 2011 4:09 AM
Subject:Re: [Shorewall-users] shorewall bridge
Hi,
According to http://www.shorewall.net/bridge-Shorewall-perl.html:
<fw> -> <BP zone> rules are not allowed
<non-BP zone> -> <BP zone> rules are not allowed
"Policies from a non-BP zone to a BP are disallowed.
Rules where the SOURCE is a non-BP zone and the DEST is a BP zone are
disallowed."
/etc/shorewall/zones defines a <BP zone> as a "subzone" of a
<non-BP zone>:
#ZONE TYPE OPTIONS
fw firewall
elsewhere ipv4
world ipv4
net:world bport
loc:world bport
So I''m supposing that one CANNOT define rules and policies such as:
<elsewhere> -> <loc>
but can define rules such as:
<elsewhere> -> <world>
Suppose that my loc zone is physically connected to eth0 and net is connected to
eth1 and that I want to allow specific IP addr/port traffic from
<elsewhere> to <net> but block it from <elsewhere> to
<loc>.
If I set this in /etc/shorewall/policy:
elsewhere world REJECT
and this in /etc/shorewall/rules:
ACCEPT elsewhere world:<SMTP_SERVER_IP_ADDR>
tcp 25
then I should be blocking all SMTP traffic except to my SMTP server.
However, I won''t be able to explicitly allow tcp 25 traffic to the
"loc" subzone of "world" and disallow tcp 25 traffic to the
"net" subzone.
Also, if the net subzone is considered "insecure" then a host in that
subzone could assign itself the same IP address as my SMTP server thus receiving
SMTP traffic illegitimately.
Is this a physdev match limitation?
Is there a solution to this other than making sure that my net subzone
isn''t "insecure"?
On the other hand, if my /etc/shorewall/policy file contains:
net elsewhere REJECT info
net world REJECT info
and a host from <elsewhere> tries to connect to
<SMTP_SERVER_IP_ADDR> and the latter is within the net bport subzone (ie.
connected to eth1 in my example) then it should fail, right?
The connection should succeed if <SMTP_SERVER_IP_ADDR> were connected to
eth0 (loc bport subzone).
Thanks,
Vieri
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
On 3/24/11 2:09 AM, Vieri Di Paola wrote:> Hi, > > According to http://www.shorewall.net/bridge-Shorewall-perl.html: > > <fw> -> <BP zone> rules are not allowed > <non-BP zone> -> <BP zone> rules are not allowed > > "Policies from a non-BP zone to a BP are disallowed. > Rules where the SOURCE is a non-BP zone and the DEST is a BP zone are disallowed." > > > /etc/shorewall/zones defines a <BP zone> as a "subzone" of a <non-BP zone>: > > #ZONE TYPE OPTIONS > fw firewall > elsewhere ipv4 > world ipv4 > net:world bport > loc:world bport > > So I''m supposing that one CANNOT define rules and policies such as: > > <elsewhere> -> <loc> > > but can define rules such as: > > <elsewhere> -> <world>Correct.> > Suppose that my loc zone is physically connected to eth0 and net is connected to eth1 and that I want to allow specific IP addr/port traffic from <elsewhere> to <net> but block it from <elsewhere> to <loc>. > If I set this in /etc/shorewall/policy: > elsewhere world REJECT > and this in /etc/shorewall/rules: > ACCEPT elsewhere world:<SMTP_SERVER_IP_ADDR> tcp 25 > then I should be blocking all SMTP traffic except to my SMTP server. > However, I won''t be able to explicitly allow tcp 25 traffic to the "loc" subzone of "world" and disallow tcp 25 traffic to the "net" subzone.Yes> Also, if the net subzone is considered "insecure" then a host in that subzone could assign itself the same IP address as my SMTP server thus receiving SMTP traffic illegitimately.Yes> Is this a physdev match limitation?Yes. Read the material at the beginning of http://www.shorewall.net/bridge-Shorewall-perl.html#Shorewall for background on why it works the way that it does. The basic problem is that the IP stack doesn''t know which port the packet is going out of until it is about to be sent (ARP packets may need to be sent to learn that). That''s too late to make a filtering decision; it was done in earlier kernels and it broke other features like IPSEC and MAC filtration.> Is there a solution to this other than making sure that my net subzone isn''t "insecure"?Sure -- don''t use a bridge in a configuration where there are other interfaces if you want to distinguish between destination bridge ports.> > On the other hand, if my /etc/shorewall/policy file contains: > net elsewhere REJECT info > net world REJECT info > and a host from <elsewhere> tries to connect to > <SMTP_SERVER_IP_ADDR> and the latter is within the net bport subzone (ie. connected to eth1 in > my example) then it should fail, right?Yes.> The connection should succeed if <SMTP_SERVER_IP_ADDR> were > connectedto eth0 (loc bport subzone). No. From <elsewhere>, the subzones are indistinguishable. -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 \________________________________________________ ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
--- On Thu, 3/24/11, Tom Eastep <teastep@shorewall.net> wrote:> On 3/24/11 2:09 AM, Vieri Di Paola > wrote: > > Hi, > > > > According to http://www.shorewall.net/bridge-Shorewall-perl.html: > > > > <fw> -> <BP zone> rules are not > allowed > > <non-BP zone> -> <BP zone> rules are > not allowed > > > > "Policies from a non-BP zone to a BP are disallowed. > > Rules where the SOURCE is a non-BP zone and the DEST > is a BP zone are disallowed." > > > > > > /etc/shorewall/zones defines a <BP zone> as a > "subzone" of a <non-BP zone>: > > > > #ZONE > TYPE > OPTIONS > > fw > firewall > > elsewhere ipv4 > > world > ipv4 > > net:world bport > > loc:world bport > > > > So I''m supposing that one CANNOT define rules and > policies such as: > > > > <elsewhere> -> <loc> > > > > but can define rules such as: > > > > <elsewhere> -> <world> > > Correct. > > > > > Suppose that my loc zone is physically connected to > eth0 and net is connected to eth1 and that I want to allow > specific IP addr/port traffic from <elsewhere> to > <net> but block it from <elsewhere> to > <loc>. > > If I set this in /etc/shorewall/policy: > > elsewhere world > REJECT > > and this in /etc/shorewall/rules: > > ACCEPT > elsewhere > world:<SMTP_SERVER_IP_ADDR> > tcp > 25 > > then I should be blocking all SMTP traffic except to > my SMTP server. > > However, I won''t be able to explicitly allow tcp 25 > traffic to the "loc" subzone of "world" and disallow tcp 25 > traffic to the "net" subzone. > > Yes > > > Also, if the net subzone is considered "insecure" then > a host in that subzone could assign itself the same IP > address as my SMTP server thus receiving SMTP traffic > illegitimately. > > Yes > > > Is this a physdev match limitation? > > Yes. Read the material at the beginning of > http://www.shorewall.net/bridge-Shorewall-perl.html#Shorewall > for > background on why it works the way that it does. The basic > problem is > that the IP stack doesn''t know which port the packet is > going out of > until it is about to be sent (ARP packets may need to be > sent to learn > that). That''s too late to make a filtering decision; it was > done in > earlier kernels and it broke other features like IPSEC and > MAC filtration. > > > Is there a solution to this other than making sure > that my net subzone isn''t "insecure"? > > Sure -- don''t use a bridge in a configuration where there > are other > interfaces if you want to distinguish between destination > bridge ports.I''m using a bridge (say "SW BOX 1") for loc and net because I have another shorewall router/gateway (say "SW BOX 2") on the net subzone doing traffic marking in a multi-ISP setup. I''m using tcrules in "SW BOX 2" to mark IP addresses within "SW BOX 1"''s loc zone so that loc hosts connect to the internet through a specific DSL provider. If I setup eth0 and eth1 as routed interfaces (no bridge) on "SW BOX 1" I need to do masquerading of the loc zone. I can allow traffic from loc to net and it will reach "SW BOX 2" but a tcpdump shows that packets come from "SW BOX 1"''s external interface IP address. How can I classify and filter traffic via tcrules and rules on "SW BOX 2" when the requests are coming from "SW BOX 1"''s loc zone? My routed setup would look like this: loc: 10.215.0.0 255.255.0.0 "SW BOX 1": eth0: 10.215.144.91 ; eth1 (net): 172.16.0.1 "SW BOX 2": eth0: 172.16.0.2 (multi-ISP gateway) My bridge setup (currently running) is like this: loc: 10.215.0.0 255.255.0.0 "SW BOX 1": br0: eth0, eth1: 10.215.144.91 "SW BOX 2": eth0: 10.215.144.92 (multi-ISP gateway) Thanks Vieri> > > > > On the other hand, if my /etc/shorewall/policy file > contains: > > net > elsewhere > REJECT > info > > net > world > REJECT > info > > and a host from <elsewhere> tries to connect to > > <SMTP_SERVER_IP_ADDR> and the latter is within > the net bport subzone (ie. connected to eth1 in > > my example) then it should fail, right? > > Yes. > > > The connection should succeed if > <SMTP_SERVER_IP_ADDR> were > > connected > to eth0 (loc bport subzone). > > No. > > From <elsewhere>, the subzones are > indistinguishable. > > -Tom------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
--- On Thu, 3/24/11, Vieri Di Paola <vieridipaola@yahoo.com> wrote:> If I setup eth0 and eth1 as routed interfaces (no bridge) > on "SW BOX 1" I need to do masquerading of the loc zone.Or maybe not... ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
On 3/24/11 9:53 AM, Vieri Di Paola wrote:> > --- On Thu, 3/24/11, Vieri Di Paola <vieridipaola@yahoo.com> wrote: > >> If I setup eth0 and eth1 as routed interfaces (no bridge) >> on "SW BOX 1" I need to do masquerading of the loc zone. > > Or maybe not... >Probably not -- use proxy ARP instead of a bridge. -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 \________________________________________________ ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
--- On Thu, 3/24/11, Tom Eastep <teastep@shorewall.net> wrote:> > --- On Thu, 3/24/11, Vieri Di Paola <vieridipaola@yahoo.com> > wrote: > > > >> If I setup eth0 and eth1 as routed interfaces (no > bridge) > >> on "SW BOX 1" I need to do masquerading of the loc > zone. > > > > Or maybe not... > > > > Probably not -- use proxy ARP instead of a bridge.Could I merely specify the “proxyarp” option on both of my firewall interfaces in /etc/shorewall/interfaces? LOC (10.215.0.0) <-> eth0 (10.215.144.91) "proxyARP option" - shorewall $FW - eth1 (172.16.0.1) "proxyARP option" <-> NET eth0 (172.16.0.2) - Multi-ISP shorewall gateway -> Internet Vieri ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
On 3/25/11 10:58 AM, Vieri Di Paola wrote:> > > --- On Thu, 3/24/11, Tom Eastep <teastep@shorewall.net> wrote: > >>> --- On Thu, 3/24/11, Vieri Di Paola <vieridipaola@yahoo.com> >> wrote: >>> >>>> If I setup eth0 and eth1 as routed interfaces (no >> bridge) >>>> on "SW BOX 1" I need to do masquerading of the loc >> zone. >>> >>> Or maybe not... >>> >> >> Probably not -- use proxy ARP instead of a bridge. > > Could I merely specify the “proxyarp” option on both of my firewall interfaces in /etc/shorewall/interfaces? > > LOC (10.215.0.0) <-> eth0 (10.215.144.91) "proxyARP option" - shorewall $FW - eth1 (172.16.0.1) "proxyARP option" <-> NET eth0 (172.16.0.2) - Multi-ISP shorewall gateway -> Internet >Yes. On the upstream interface, your subnet mask should be 255.255.255.255 (/32) and you add a single host route to the upstream router. -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 \________________________________________________ ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
--- On Fri, 3/25/11, Tom Eastep <teastep@shorewall.net> wrote:> > --- On Thu, 3/24/11, Tom Eastep <teastep@shorewall.net> > wrote: > > > >>> --- On Thu, 3/24/11, Vieri Di Paola <vieridipaola@yahoo.com> > >> wrote: > >>> > >>>> If I setup eth0 and eth1 as routed > interfaces (no > >> bridge) > >>>> on "SW BOX 1" I need to do masquerading of > the loc > >> zone. > >>> > >>> Or maybe not... > >>> > >> > >> Probably not -- use proxy ARP instead of a > bridge. > > > > Could I merely specify the “proxyarp” option on > both of my firewall interfaces in > /etc/shorewall/interfaces? > > > > LOC (10.215.0.0) <-> eth0 (10.215.144.91) > "proxyARP option" - shorewall $FW - eth1 (172.16.0.1) > "proxyARP option" <-> NET eth0 (172.16.0.2) - > Multi-ISP shorewall gateway -> Internet > > > > Yes. On the upstream interface, your subnet mask should be > 255.255.255.255 (/32) and you add a single host route to > the upstream > router.Sorry I'm off-track (first time trying out proxy ARP) but What is exactly the "upstream interface"? Is it $FW's eth0 in my example? Do you mean the following? LOC (10.215.0.0/255.255.0.0) <-> eth0 (10.215.144.91/255.255.255.255) "proxyARP option" - shorewall $FW - eth1 (172.16.0.1/255.255.255.240) "proxyARP option" <-> NET eth0 (172.16.0.2/255.255.255.240) - Multi-ISP shorewall gateway -> Internet ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users